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(57) Abstract: System and method for 
performing application server load balancing. 
Requests may be mapped from a client 
computer(s) lo a set of application servers 
configured in a cluster. In various embod- 
iments, different load balancing methods 
and criteria may be used. For example, the 
cUent computer(s) may be operable to make 
the load balancing decisions. e.g„ based 
on the lowest response time seen from the 
^plication servers. The system may also be 
configured so that load balancing decisions 
are made by load balancing services running 
on die application server computers, A 
variety of load balandng criteria may be 
used, including server load factors such as 
CPU load, disk input/output rate, number of 
requests queued, etc. Decisions may also take 
into account various application con^Kjnent 
performance criteria, such as the application 
server that most recently ran a component or 
whether or not cached results for a component 
are available on an application servec. The 
application server system may also support 
"sticky" load balandng, so that requests 
issued within the context of a particular 



V *• ^«.«n«pni nrP flll nrocesscd bv the application component instance running on the same 
winner-take-most rather than a winner-take-all suategy. 
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TITLE: GRACEFUL DISTRIBUTION IN APPLICATION SERVER LOAD BALANCING 



BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to the field of appUcation servers, and more particularly to a system and 

various methods for performing application server load balancing. 



2. Description of the Related Art 

The field of appUcation seiveis has recently become one of the fastest-growing and most in^5ortant fields 
in the computing industry. As web applications and other distributed appUcations have evolved into large-scale 
applications that demand more sophisticated computing services, specialized application servers have become 

15 necessary, in order to provide a platfonn supporting these large-scale appUcations. AppUcations that run on 
appUcation servers are generaUy constructed according to an n-tier architccUire, in which presentation, business 
logic, and data access layers are kept separate. Hie appUcation server space is sometimes referred to as 
^'middleware", since appUcation servers are often responsible for deploying and running the business logic layer 
and for interacting with and integrating various enterprise-wide resources, such as web servers, databases, and 

20 legacy systems. 

AppUcation servers offer significant advantages over previous approaches to implementing web 
appUcations, such as using common gateway interface (CGI) scripts or programs. Figure 1 illustrates a typical 
architecture for a web appUcation utiUzing CGI scripts or programs. Hie cUent computer running a web browser 
may reference a CGI program on the web server, e.g., by referencing a URL such as "http://server.domain.cam/cgi- 
25 bin/myprogram.pr. GeneraUy. the CGI program runs on tiie web server itself, possibly accessing a database, e.g. 
in order to dynamically generate HTML content, and the web server returns the output of the program to the web 
browser. One drawback to this approach is that the web server may start a new process each time a CGI pr 

script is invoked, which can resuU in a high processing overhead, impose a Umit on the number of CGI programs 
that can run at a given time, and slow down the performance of the web server. In contrast. appUcation servers 
30 typically provide a means for enabUng programs or program con^wnents that are referenced via a URL to run on a 
separate con^uter from the web server and to persist between cUent invocations. 

Another common drawback of previous web appUcation design models, such as the use of CGI programs, 
is related to data access. For exan^le, if a CGI program needs to access a database, the program typically opens a 
database comiection and then closes the comiection once it is done. Since opening and closing database 
35 comiections are expensive operations, these operations may further decrease the performance of the web server 
eadi time a CGI program runs. In contrast. appUcation servers typically provide a means to pool database 
connections, thus eUminating or reducing the need to constantiy open/close database connections. Also, data access 
in CGI programs is generally coded at a relatively low level, e.g., using a specific dialect of SQL to access a 
specific type of database. Thus, portions of the appUcation may need to be rccoded if the database is replaced with 
40 a new type of database. AppUcation servers, on the other hand, may provide a database service for appUcations to 
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utilize as an interface between the appUcation and the database, which can serve to abstract the apphcation from a 
particular type of database. 

AppUcation servers may also provide many other types of apphcation services or may provide standard 
reusable components for tasks that web applications commonly need to perform. AppUcation servers often 
incorporate these services and components into an integrated development environment specialized for creating 
web applications. The integrated development environment may leverage various standard software component 
models, such as the Common Object Request Broker Architecture (CORBA), the (Distributed) Component Object 
Model (COMmCOM), Enterprise JavaBeans™ (EJB), etc., or the integrated development environment may 
provide its own software component model or may extend standard component models in various ways. 

The foUowmg list is a partial list of the types of appUcation services or appUcation con^onents diat 
appUcation servers may provide. By leveraging these types of integrated, pre-built services and components, web 
appUcation developers may realize a significant reduction in appUcation development time and may also be able to 
develop a more robust, bug-free application. AppUcation servers from different vendors differ, of course, in the 
types of services they provide; thus, the following Ust is exemplary only. 

♦ As noted above, appUcation servers may provide data access services for accessing various types of databases, 
e.g- through direcdy supporting proprietary databases, such as SAP, Lotus Notes, OCS, etc. or tiirough 
standardized interfaces, such as ODBC, JDBC, etc. Also, as noted above, appUcation servers may enable 
database connection pooling or caching. 

. AppUcation servers may also provide services for accessing network directories, such as directories that 
Siwort the standard Lightweight Directory Access Protocol (LDAP). 

♦ AppUcation servers may also provide appUcation security services or components. Web application security 
25 may be considered at different levels, such as: cUent-to-server communication, appUcation-level privileges, 

database access, directory service access, etc. Application server security-related services/components may 
mclude support for performing user authentication, performing data encryption, communicating via secure 
protocols such as Secure Sockets Layer (SSL), utiUzing security certificates, prograimning user access rights, 
integratmg with operating system security, etc. 



15 



20 



30 



. AppUcation servers may also provide services enabUng a web appUcation to easily maintain user state 
information during a user session or across user sessions. Performing state and session management is 
especially iinportant for appUcations diat have complex, multi-step transactio 

35 . AppUcation servers may also support caching the results of appUcation logic execution or caching the results of 
web page/component output, so that for appropriate subsequent requests, the results may be reused, 

. AppUcation servers may also support result streaming, such as dynamically streaming HTTP output, which 
may be especiaUy usefid for large result sets involving lengtiiy queries. A related service may enable an 
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application to easily display a large result set by breaking the result set down into smaller groups and 
displaying these groups to the user one at a time. 

• Many web applications need to perform various types of searching or indexing ope^ 
5 may also provide application services for indexing or searching various types of documents, databases, etc. 

. As noted above, many web applications may perform various types of compUx^ multi-step transactions. 
AppUcation servers may also provide support for managmg these application transactions. For example, this 
support may be provided via a software componem model supported by the appHcation server, such as the 
10 Enterprise JavaBeans™ component model, or via integration with third-party transaction process monitor, etc. 

• It is often desirable to enable web appUcations to perform certain operations independently, as opposed to in 
response to a user request For example, it may be desirable for an appUcation to automatically send a 
newsletter to users via email at regularly scheduled intervals. Application servers may support the creation and 
15 scheduling of events to perform various types of operations. 

. Many types of web appUcations need to perform e-commerce transactions, such as credit card transactions, 
financial data exchange, etc. AppHcation servers niay provide services for performing various types of e- 
commcrce transactions or may provide an integrated tod-party e-commerce package for applications to use. 



20 



» Web applications often need to utihze various types of standard network appUcation services, such as an email 
service, FTP service, etc. AppUcation servers may provide these types of services and may enable appUcations 
to easily integrate with the services. 

25 . Web appUcations often need to log various conditions or events. AppUcation servers may provide an 
integrated logging service for web applications to use. 

Judging by the exenq>lary list above of computing services that appUcation servers may provide for web 
appUcations, it is apparent that appUcation servei^ may integrate a diverse range of services, where these services 
30 may interact with many different types of seivers, systems, or odier services. For example, an appUcation server 
may act as a platform hub connecting web servers, database servers/services, commerce servers/services, legacy 
systems, or any of various other types of systems or services. A key benefit o 

not only provide this service/system integration, but typically also provide ccntraUzed administrative or 
management tools for pcrforrning various aspects of system and application adn^ 
35 For example, appUcation servers rnay provide management took reUted to 

deployment, such as tools for source code control and versioning. bug tracking, workgroup development, etc. 
AppUcation servers may also provide tools related to appUcation testing and deployment, such as tools for 
appUcation prototyping, load siinulation, dynamic code base updates, etc. AppUcation servers may also provide 
took for easily configuring the appUcation to utiUze various of the application serve^^ 
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example, administrators may use a tool to set the result caching criteria for particular application components or 
pages, or may use a tool to specify which documents to index or to specify indexing methods, etc. 

One important class of appUcation server administrative tools pertains to real-time application 
management and monitoring. Application servers may provide tools for dynamically managing various factors 
affecting application performance, e.g. by adjusting the application services and support features described above. 
For example, appUcation server tools may allow administrators to: 

• dynamically adjust the number of database connections maintained in a database pool, in order to detemiinc 
the optimmn pool size for maximum performance 



• clear or resize application output caches 

• dynamically change various aspects of system or application security 

15 • schedule or trigger events, such as events for sending e-mail reports to appUcation users, generating reports 
based on coUected data, etc. 

• start and stop various application services, such as email or FTP services, from a centralized user interface 

20 This Ust is, of course, excnqilary, and particular appUcation servers may support different types of centraUzed 
appUcation management. 

In addition to Ae factors discussed above, many appUcation servers also include means for providing 
various types of system reUabiUty and fault tolerance. One common technique related to fault tolerance is Icnown 
25 as appUcation server "clustering". AppUcation server clustering refers to tying together two or more appUcation 
servers into a system. In some cases, this **tying together" may mean that appUcation code, such as particular 
software components, is repUcated on multiple appUcation servers in a cluster, so that in the case of a hardware or 
software failure on one appUcation server, user requests may be routed to and processed by other appUcation 
servers in the cluster. 

30 AppUcation server clustering may also faciUtatc application performance and scalabiUty, AppUcation 

servers may be added to a cluster in order to scale up the avaUable processing power by distributing work. 
Advantageously, appUcation servers often enable this type of scaUng up to be down without requiring changes to 

the appUcation code itself, " 

Work may be distributed across an appUcation server cluster in different ways. For example, as discussed 

35 above, appUcation code may be replicated across multiple appUcation servers in the cluster, enabling a given 

request to be processed by any of these multiple appUcation servers. Also, appUcation code may be logically 

partitioned over multiple servers, e.g.. so that a particular appUcation server is responsible for performing particular 

types of operations. This type of appUcation partitioning may help appUcation. performance in various ways. For 

example, appUcation partitioning may reduce the need for an appUcation server to perform context switdiing 
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between different types of operations, such as CPU-intensive operations versus input/output-intensive operations. 
Also, application partitioning may be used to match application processing to various physical characteristics of a 
system, such as network characteristics. For example, data-intensive application logic may be configured to nm on 
an application server that is closest to a data source, in order to reduce the latencies associated with accessing 

5 remotely located data, 

hi the case of apphcation code replication, where multiple appHcation servers are enable of processing a 
given request, it is often desirable to route the request to die *1>esr application server cunently available to process 
the request The "besf * application server may, for exan^le, be considered as the appUcation server that will enable 
the request to be processed and the request results to be returned to the client as quickly as possible. On a broader 
10 scale, the n)est" application server may be considered as the appUcation server that will enhance some aspect of the 
perfbnnancc of the overaU application to the greatest possible extent The mapping of cUent requests to appUcation 
servers, which may use various algorithms and techniques, is known as "appUcation server load balancing." 

Existing application servers often provide Hmited support for appUcation server load balancing. For 
example, many application servers enable a cUent computer, e.g. a web server, to broker requests to appUcation 
15 servers in a cluster m a round-robin manner. Some application servers also support load balancing decisions that 
are based on statistics indicative of the current load carried by each appUcation server, such as current CPU load, 
current number of requests queued, disk input/output rate, etc. 

However, given the great disparity in types of appUcations tiiat may run on appUcation servers and the 
performance needs of these appUcations. existing appUcation servers often do not provide load-balancing 
20 capabilities tiiat are sophisticated enough to maximize application performance. In particular, it may be deshable to 
make load-balancing decisions on a winncr-take-most basis rather than a winncr-takc-all basis, so that the ^'bcsC 
appUcation server at a given moment docs not suddenly become overloaded relative to other appUcation servers in 
the cluster. 

25 SUMMARY OF THE INVENTION 

The problems outlined above may in large part be solved by a system and method for performing 
appUcation server load balancing, as described herein. AppUcation servers may support networked applications, 
such as web appUcations or other Internet-based appUcations. One or more client computers, e.g.. web servers, may 
perform requests referencing appUcation con^nents, such as Enterprise JavaBeans™ conqwnents, Java™ Servlets, 

30 aC++ components, etc., on the appUcation server. The system may also be configured to utiUze a cluster of 
appUcation servers in which application cort^nents are replicated across multiple appUcation servers in the cluster. 
In this case. appUcation server load balancing may be performed, as described above. 

In various embodiments, load balancing decisions may be made in many different ways. For example, the 
cUcnt computer(s) may be operable to make die load balancing decisions. For example, as described below, a web 

35 server cUent conq>uter may comprise a load balancing plug-in component, e.g. anNSAPI or ISAPI congionent, ftat 
tracks dynamic appUcation information and performs the load balancing based on tiiis information. In one 
embodiment the plug-in may track the time it takes for requests sent to each application server to be returned and 
may send a request to the appUcation server with the fastest response time. For exarr^le, it may be determined that 
die average response time to service requests referencing a particular application component are significantly lower 
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for one application server in the cluster. For another apphcation component, a different application server may 
provide the lowest response time. 

Client computers may also be operable to perform load balancing decisions based on algorithms such as a 
round-robin algorithm. In one embodiment, a weighted version of the round-robin algorithm may be siqjportcd. 
5 In various embodiments, the system may also be configured so that load balancing decisions arc made by 

load balancing services running on the application server computers. A variety of load balancing criteria may be 
used, including server load factors such as CPU load, disk input/output rate, number of requests queued, etc 
Decisions may also take into account various application component performance criteria, such as the application 
server that most reccnUy ran a comqjonent or whether or not cached results for a component arc available on an 
10 application server. Load balancing criteria may be broadcast among application server computers at configurable 
intervals, e.g., via User Datagram Protocol (UDP) multicasting. 

The application server system may also support "sticky** load balancing. Administrators may specify a 
particular application conqjoncnt to require sticky load balancing so that requests issued within the context of a 
particular session that reference that application component arc all processed by the application component instance 
15 running on the same apphcation server. The initial decision as to which apphcation server should process a request 
referencing a sticky component may be made using the same factors as for other requests, but subsequent requests 
may be sent to the same server that processed the initial request Sticky load balancing may be useful, for cxainple, 
for apphcation corrqx)ncnts that rely on session information that camiot be distributed across apphcation servers. 
The cHent computer(s) rnay be operable to inaintain infoiination regarding sticky requests so that sti 
20 can be sent directly to the correct apphcation server. 

In various embodiments, the apphcation server system may also enforce even distributicm of sticky 
requests. As noted, the initial request to a component requiring stickiness may be made using noraial load 
balancing methods, such as those described above. To avoid a large number of sticky requests bmding to the "bcsT 
apphcation server at any given time, the system may track information regarding the number of sticky requests that 
25 are currently bound to each apphcation server and may force the sticky requests to be distributed roughly evenly. 
In one embodiment, administrators may assign a weight to each apphcation server, based on the particular hardware 
or other capabihties of the computer, and the sticky requests may be distributed in proportion to these weights. 

A related concept is that of "graceful distribution." As described above, load balancing decisions may be 
made based on statistics, such as server load criteria or apphcation component performance criteria, that are shared 
30 periodically among apphcation servers. Since the information available to the load balancing service will usually 
lag behind the real data somewhat, the result may be that, at any given time, the **besr apphcation server receives 
all the requests. This may cause apphcation servers to undergo spikes in which they suddenly beconac overloaded 
relative to other apphcation servers in the cluster. Thus, m various embodiments, the system may support 
"graceful distribution** methods that utilize a wirmer-take-iriost rather than a wim 
35 As described below, a user interface may be provided to enable apphcation administrators to set 

information specifying v^ch load balancing methods should be used, adjtist load balancing criteria weights, etc 
The user interface may provide a centralized location for administrators to manage the load balancing for an 
apphcation server system. ' 
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BRIEF DESCRIPTION OF THE DRAAVINGS 
Other objects and advantages of the invention wiU become apparent upon reading the following detailed 

description and npon reference to the accompanying drawings in which: 

Figure 1 iUustrates a typical archHectme for a web apphcation utilizm 
5 Figures 2A - 2C illustrate excnqslary architectures for networked applications running on application 

servers; 

Figure 3 is a block diagram illustrating one embodiment of an application server and processes that run on 
the application server; 

Figure 4 iUustrates several system-level services that may be involved in managing appUcation server 
10 requests; 

Figures 5 and 6 ilhistrate various embodiments of a web server cUent with a web sc^ 
a load halanccr component that distributes requests across an appUcation server chistcr. 

Figure 7 illustrates a cluster of appUcation servers in which each appUcation server comprises a load 
balancing service; 

15 Figure 8 iUustrates a table of exemplary server load criteria that may be used in deciding which ^Ucation 

server is best able to process a current request; 

Figure 9 illustrates a table of cxenq^lary appUcation conqwncnt performance criteria that may be nsed in 
deciding which appUcation server is best able to process a current request; 

Figure 10 iUustrates an exenqjlary user interface screen for setting server load criteria values; 
20 Figure 11 iUustrates a user mterfacc partial tree view of appUcation servers in an appU^^^ 

Figure 12 illustrates an exen^lary user interface screen for setting appUcation consent performance 
criteria values; 

Figure 13 Ulustrates an exemplary user interfece screen for setting broadcast and xtpdsic intervals for 
sharing load balancing infornmtion among appUcation servers in an appUcation 
25 Figure 14 Ulustrates an cxenq>laiy user interface of a tool for enabUng administrators to specify "sticky" 

load balancing for certain appUcation couHJoncnts; 

Figure 15 is a flowchart diagiam illustrating one embodiment of a method for enabUng appUcation server 

request Mover; 

Figure 16 is a flowchart diagram iUustrating one embodiment of a metiiod for dynamical 

30 and reloading classes; 

Figure 17 is a flowchart diagram iUustrating one embodiment of a method for determining whete a class 

should he dynamically reloaded when modified; 

Figure 18 is a flowchart diagram iUustrating one embodiment of a method for p^^ 

loading; 

35 Figure 19 is a flowchart diagram iUustrating one embodiment of a method for enabUng JSP response 

caching; 

Figure 20 iUustrates an exenn'lary user interface of a tool for managing message logging; 
Figure 21 iUustrates an exen:?)lary type of database table for logging messages; 
Figure 22 iUustrates an exenqilary type of database table for logging Hrn> re^^ 
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Figui^ 23 is a nowchait diagram Ulustrating one embodiment of a method for handling out-of-storage- 
space conditions when logging messages. 

While the invention is susceptible to various modifications and alternative fonns. specific embodiments 
are shown by way of exan^le in the drawings and are herein described in dctaiL It should be understood however, 
that drawings and detailed description thereto are not intended to limit the invention to the particular form 
disclosed, but on the contrary the invention is to cover all modifications, equivalents and alternatives falling within 
the spirit and scope of the piesem invention as defined by the appended claims. 

DETAILED DESCRIPTION OF THE PREFERRED EMB ODIMENTS 

Figure 2 - Exemplary Application Architectures 

Figures 2A - 2C illustrate exerr5)lary architectures for networked appHcations running on appUcation 
servers. There are, of course, many possible architectural variations, and Figures 2A-2C are exen^laryonb^^ 

Figure 2A illustrates an exemplary architecture for a web application. In general, a web appUcation may 
be defined as an Internet or Intranet-based application comprising a collection of resources that are accessible 
through uniform resouree locators (URLs). TTie resources may include web pages comprising HTML, XML. 
scripting code such as Javascript or VBScript, or other types of elements. The resources may also mctode any of 
various types of executable programs or components, such as CGI programs. Java servlets. JavaBeans components, 
CORBA components, downloadable code such as Java classes or ActiveX components, etc. The resources may 
also include any other type of resource addressable through a URL. 

The embodiment of Figure 2A illustrates a cUcnt computer 100 running a web browser, sudi as the 
Netscape Navigator or Microsoft hitemet Explorer web browsers. It is noted that the web-browser need not be a 
web browser per se. but may be any of various types of cUent-side applications that include web-browsing 
fimctionality. For example. Microsoft Corp. provides prograrmning interfaces enabling applications to incorporate 
various web-browsing capabiUties provided by the Microsoft Internet Explorer code base. 

The web browser may run in any type of cUent computer 1 00. For example, the web browser may run in a 
desktop computer or workstation running any of various operating systems, such as Windows. Mac OS. Unix. etc.. 
or the web browser may run in a portable computing device, such as a personal data assistant, smart celhilar phone, 
etc. The cUent computer 100 may use a network connection for communicating with a web server 104 via a 
network 102, such as the Internet or an Intranet n»c cUent network com>ection may be a comiection of any type, 
such as a PPP or SLIP dialup link, an Ethernet or token ring connection, an ISDN comiection. a cable modem 
connection, any of various types of wireless comiections, etc. Although web appUcations are often associated with 
particular communication protocols, such as HTTP or SSL. it is noted that any commmiication protocol, inchrding 
■TCP-based protocols and LfDP-based protocols, may be used to communicate over the network 102. 

As the web server 104 receives a request fiom a chcnt computer 100, tfH: web server rnay treat the rw^^ 

differentfy, depending on the type of resource the request references. For example, if the request references a 
docmnent 106. such as an HTML docmnent, then the web server may process the request itscli; e.g., by retrieving 
. the document from the web server's local file system or from a local cache and returning the document to the client 
computer. For other types of requests, e.g. requests referencing executabk components, such as Java servlets. 
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JavaBea,. components, C prograna modules. CORBA components, etc. the web server may broker ihe request to 
an application server 108: AS descnTK^d in more .fctail below, the web server IM ma^ 

server through an in-process extension, such as an ISAPl or NSAPI extension. 

TT.e appHcation server 108 may be configured as a part of an appKcation server cluster, as desc^ 

5 and shown in Figure 2A. Although Figure 2A illustrates an appUcation server cluster with only two application 
servos it is noted that the chistcr may comprise any number of appUcation servers. Each application server may 
interface with various types of other servers or systems. For example, as illustrated in Figure 2A, the application 
servers may commumcate with a database 110. Each application server in the cluster may interfece with the same 
systems or .he application servers may differ in which systems they interface with. For example. F,g«e 2B .s 

XO similar to Figure 2A, but in the embodhnem of Figure 2B. appHcation server 108B is shown 1o iolerfccc wrth a 
legacysystemnXAppKcationserversinaclustcrrnaynotneedtobeincloscphysicalproxim^ 

It is noted that, in alternative embodiments, a chent computer may commmdcatc directly wA 

application server or application server cluster, without mterfacing through a web server. Figure 2C iKustmtes . 
cUent computer 114 communicating direcUy with application servers 108. For example, the appUcadon servers 

15 may rm, an enterprise resource plamung application, and d>e cUent computer 114 may be a computer within the 
enten^rise that is connected to the application servers via a WAN. In this example, the client computer may «m 
.^ck client" software, eg., client software that comprises a portion of the enterprise resource plamung apphcatmn 
logic Tl»eclientcomputersoiWmayinterfacedirectlywithexecutableprog,amsorco^ 
appUcationserveis.e.E.throughaprotocolsuchas.heInte,netInter-0.bProtocol^^^^^ 

20 Asno,edabove.FiBures2A-2Careexempla.yarchitecmresonly,andmanyvariatiansareposs^^ 

snudl handful of examples of alternative embodiments, multiple web senders may be present to receive requests 
client computers and broker the requests to appUcation servers, the web server may itself interface dn«:^ 
with a database. appUcation servers may interfile with various o^^^ 
authentication serven;, e-cominerce servers, etc. 

25 

Figure 3 - Service and Com ponent Management 

AppUcations that rm> on appUcation servers are often constructed fiom various types of software 
components or modules. Tl.ese components may include components constructed according to a standard 
c^nponentmodcL For example, an appUcadon may comprise various types of standard Java™ com^ 
30 EnterpriseJavaBeans~components,JavaServerPages™ JavaSexvlets™. etc. An appUcation may dso comprrsc 
any of various other types of components, such as Common Object Request Broker Axchitccmre (CORBA) 
components. Common Object Model (COM) components, or components constmCed according to 

proprietary component models. 

Each request that «! appUcation server receives ftom a cUen. may reference a pardcular appUcahon 
35 component Uponreceivingareques^theapplicationservermaydeterm^ 

component,andretumtheexecudonresultstothecUent In various embodiments, it may be necessary or desnable 
for differo^ types of appUcation server components to nm within different envi«^ 
appUcation server may support both components written using the Java~ prognnmnm 
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written using the C or piogramming languages. In such a case, the different types of components may be 
managed by particular processes or engines. 

For example, Figure 3 illustrates an application server 200 in which a process refencd to 88 thp "executive 
server" 202 runs. As shown, the executive server 202 interfaces with a process 204. referred to as a "Java server" 
5 and a process 206 referred to as a "aC++ server". In this embodiment, the executive server 202 nay receive clietit 
requests, assign the client requests to a particular teead, and forward the requests to either the Java senrer204 or 
the C/C++ server 206. depending on whether the requests reference a component that executes within a Java 
nmtime environment or a CIC^ runtime enviromnent The Java server or aC++ server may then load and 
execute the appropriate component ormodulc. 
10 In addition to interfacing witti the Java and aC+-+ servers, the executive server 202 may also manage 

various system-level services. For example, as discussed below, the executive server may manage a load balancing 
service for distributing requests to other appUcation server computers in a cluster, a request numager service for 
handling incoming requests, a protocol manager service for communicating with clients using various protocols, an 
event logging service for recording conditions or events, etc. 
15 In addition to managing application components, the Java server 204 and the C/C++ server 206 may also 

host and manage various application-level services used by the appUcation components. n>ese appUcation-level 
services may inctodc services for managing access to databases and pooling database com«ctions. services for 
perfomring state and session management, services for caching output results of particular appHcation components, 
or any of various other services such as described above. 
20 Figure 3 also illusbates a process 208 referred to as the "administrative server". As described above, an 

application server enviromnent may provide an administrative tool for adjusting various fectors affecting 
appHcation execution and perf-ormance. In die embodiment of Figure 3, such an administrative tool may interface 
with the administrative server 208 to adjust ti>ese factors. For example. ti.e administrative tool 208 may be enabled 
to adjust the event logging criteria used by the executive server's event-logging service, adjust the number of 
25 database connections pooled by the Java or C/C++ server's data access service, etc. Hie administiative server 208 
may also provide failure recovery by monitoring the executive server. Java server, and aC++ server processes and 

restarting these processes in case of failure. 

Figure 3 of course represents an exeinplary architecture for managing appUcation components, system 

level services, and appUcation-level services, and various other embodiments are contemplated. For example. 
30 although Figure 3 is discussed in terms of Java™ and C/C++ components, various other processes or engines may 
be present for executing oti^ types of software components or modules. Also, various embodiments may s^ 

multiple component management processes. e.g. multiple Java server processes or aC++sm^ -n-e 
mmd«r of processes may be adjusted via an administiative tool interfacing with the ad^^ 

35 Fi pgc 4 - AppUcation Server System- Eevel Services 

Figure 4 illustrates several system-level services which may be involved m nianaging appUcation server 
^ts. h, one embodiment, tiiese system-level services may be managed by an executive server process such as 
described above widi reference to die Figure 3 appUcation server. 
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Figure 4 illustrates a protocol manager service 220. The protocol manager service 220 is responsible for 
managing network cotmnunication between the application server 230 an4 clients of the q>pUcati(m server. For 
example. Figure 4 iUustrates a web server client 240 which comprises a standard web server extension or plug-in 
242. The web server plug-in 242 may be any of various well-known types of phig-ins enabling web servers to 

5 communicate wiA other systems, inchiding NSAPI, ISAPI, optimized CGI, etc. As shown, tfic protocol man^ 
service 220 includes "listener" modules or con^onents, e.g. an NSAPI listener, ISAPI listener, etc, for 
communicating with the web server plug-in. Tlie listener modules may communicate with the web server phig-in 
via the standard HTTP or HTTPS protocols. 

Figure 4 also illustrates that other types of cUents besides web servers may communicate widi liic 

10 application server 230. For exanq)le. a client computer 250 is shown. The cUcnt con^nitcr 250 may lun an 
application program, such as a program written in Java™ or C^-H, t^^ 

230 using any of various communication protocols. For cxanq)le, as shown in Figure 4, the protocol manager 
service 220 may support such protocols as HOP, RMI, DCOM, OCL Service, or any of various other protocols. As 
an example, an administration program for configuring an application server may communicate dirccdy wilb the 
15 apphcation server 230 through such a protocol, rather than routing requests through a web ^ 

As shown in Figure 4, an application server may also include a load balancing service 222. In die case of 
plication server clustering, requests may first be processed by the load balancing service in order to determine 
whether the request should be processed by the current appUcation server or would b^ 
the request to anodier apphcation server in the cluster. Load balancing is dis 
20 As shown in Figure 4, an appUcation server may also include a request manager service 224. Once die 

load balancing service determines that the current appUcation server should process the cUent request (if load 
balancing is applicable), the request manager service is responsible for managing die processing of die request As 
shown in Figure 4, die request manager service 224 may inchide several conqwnents or modules, such as a request 
manager, a duead manager, and a queue manager. In one embodiment, client requests may be processed in a multi- 
25 direaded fashion. The diread manager module may manage a pool of threads available for processing requests. In 
one embodiment, fee number of dueads in die pool may be adjusted using an administrative tooL 

When die request manager module receives a cUent request, die request manger module may caU the 
diread manager module to attempt to assign die cUent request to a diread. If no direads arc curicndy available, dicn 
die request manager module may call die queue manager module to queue die request until a diread becomes 
30 available. The queue manager module may maintain information regarding each cUcnt request, such as die request 
ID, die processing status, etc. 

XppHeation Server Load Balancing 

As discussed above, it is often desirable to configure a cluster of application servers so diat cHent requests 
35 may be distributed across die cluster, ic., to perform application server load balancing. Given die diverse nature of 
applications diat may be deployed on appUcation servers, it may be desirable to provide a system whose load 
balancing criteria are highly configurable using many different factors in order to achieve optinaal appUcation 
performance. This section discusses several load balancing ^ediods. In various embodiments, appUcation servers 
may support any of diesc load balancing mediods or any combination of die load balancing mediods described. 
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Load Balancing Dctcnnined by Web Server Plug-In 

One general approach which may be used in selecting an application server to send a request to is to leave 
the decision to the client The client may keep track of the response times seen over time firom various application 
servers and may choose to send requests to the application server with the historically fastest response times. In 

5 many cases, the "client** of an application server is a web server. As shown in Figure 4, a web server may have a 
web server plug-in which includes a load balancer component or module. This load balancer component may be 
responsible for monitoring which application servers are available in a cluster to service requests, may record the 
response times seen for requests serviced by each application server, and may use this information to detemiixic the 
most appropriate application server to send a given request to. 

10 The load balancer component of the web server plug-in may be configured, using an administrative tool, to 

xise different levels of granularity in making the response time decisions. As discussed above, client requests 
generally reference a particular executable component on an application server. For cxan^le, a URL such as 
**ht^://servcr.domain.com/abcjsp*' may reference a JavaServer Page™ component, "abc-jsp". In an excnqiiary 
system in which the "abc.jsp" component is replicated across Aree application servers. Application Server A, 

15 Application Server B, and Application Server C, the average response time, as seen firom the time the request 
referencing the **abc.jsp" component is sent to the application server to the time the request results are received 
firom the application server, may be as follows: 

Application Server A: 0.7 sec 

20 Application Server B: 0.5 sec 

Application Server C: 13 sec 

In such a case, it may be advantageous to enable the load balancer conqjonent of the web server to send a reqtiest 
referencing the "abc jsp" conponent to Application Server B. In other words, load balancing may be performed on 

25 a **pcr^omponent** basis, where each request referencing a particular conq)onent is sent to the application server 
which has historically responded to requests for that component the fastest 

Performing load balancing on a per-con^onent basis may benefit application performance fox certain 
types of applications. However, for other applications, tracking such response-time information on a pcr- 
coirq^oncnt basis may result in overhead that outweighs the benefits. Thus, the load balancer conqjoncnt of the web 

30 server may also make decisions on a **pcr-server^ basis. TTiat is, the determination of which application server to 
send requests to is based on the average response time for all requests. It is noted that in one embodiment the per- 
server and per-con^nent methods may be combined, so that administrators may specify a particular set of 
con:gK)ncnts for which the load-balancing decisions are made based on a per-con^onent basis, while decisions are 
made on a pcr-server basis for default con^onents. 

35 Figure 5 illustrates one embodiment of a web server cHent 300 with a web server plug-in 302 con^jrising a 

load balancer component 304 which distnbutes requests across an application server cluster (appUcatipn servers 
308A - 308C). As shown, the load balancer component 304 may maintain a table or list of response times 306, to 
be used in making load balancing decisions as described above. 
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The client, e.g., the load balancing component of the web sciveT plug-in, may also make load balancing 
decisions based on factors other than response times. For example, in one embodiment, administrators may assign 
a "weight" to each application server in a cluster, using an administrative tool. A weight may be assigned to each 
appUcation server based on the server's resources, such as the number of CTUs. the memory capacity, etc. The 
5 appMcation server weights may then be used in various request distribution algorithms, such that requests arc 
distributed among the appUcation servers in proportion to their weights. For example, weights may be used in a 
weighted round-robin algorithm or may be applied to enforce even distribution for certain types of lequesB, as 
described below. 

Figure 6 illustrates one embodiment of a web server cheat 300 with a web server plug-m 302 con^mg a 
10 load balancer conqjonent 304 which distributes requests across an appUcation server cluster (appUcation senreis 
308A - 308Q. As shown, a weight is assigned to each appUcation server in&e ctoster. and fte weights are used i^ 

a weighted load balancing algorithm. 



IS 



Load Balancing Detetinmed by AppUcation Server Load B alancing Service 

histead of leaving load balancing decisions to the cUent, based on such factors as response times and 
server weights, in various embodiments the appUcation servers themselves may be responsible for distributing 
requests among different computers in the appUcation server cluster. For example, in the Figure 4 example, the 
appUcation server 230 comprises a load balancing service 222 that performs request load balancing. Figure 7 
illustrates a cluster of appUcation servers 320A - 320D in which each appUcation server comprises a load balancing 
20 service 330. 

The load balancing services of the application servers may share information to bc nsed m deciding which 
appUcation server is best able to process a current request One class of information fliat may be factored into this 
decision is referred to as "server load criteria." Server load criteria inchidcs various types of information that may 
be indicative of how 'tusy" an appUcation server currently is. such as the CPU load, the input/output mte. etc. 

25 Figure 8 illustrates a table of exemplary server load criteria. Any of various oflier factors affecting server 
performance may be considered in odier embodiments. 

Another class of information that may be factored mto load balancing decisions is referred to as 
"appUcation component performance criteria". AppUcation compoiient performance criteria mcludes information 
regarding the performance of a particular appUcation component. e.g. a particuhir JavaScn^er Pages™ CO 

30 Figure 9 ilhisliates a table of exemplary criteria that may affect application conronentperfo For example. 

Figure 9 illustrates a -Cached Results Available" criterion. As discussed below, in various embodiments, ihe 
execution results of appUcation components, such as JavaServer Pages™ components, may be cached Reusing 
execution results cached on a particular appUcation server may result in faster ptoccssmg of a request 

Another exemplaiy criterion Usted m Figure 9 is "Most Recenfly Executed". For some types of 
35 appUcation components, distributing a request to the appUcation server that most recently ran the appUcation 
component referenced by the request may result in faster processing, since that appUcation server may stiU have 
context information for ttie appUcation component cached. 

Another exen5)hiy criterion Usted in Figure 9 is "Fewest Executions". In some cases, it may be desirable 
to distribute different types of requests evenly across all appUcation servers in a cluster. Thus, the appUcation 
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server that has ran the application component referenced by a request the fewest number of times may be chosen to 
process the request 

Any of various other factors regarding application component performance other than those listed in 
Figure 9 niay be used in other embodiments. 

Figures 10-12 illustiate an exen^lary user interface of an administrative tool for adjusting load balancing 
factors such as those described above. Figure 10 illustrates a user mtcrface screen for setting server load criteria 
vahies, such as those shown in the Figure 8 table. Administrators may adjust the wcigjit for each fector as 
appropriate, in order to maximize perfonnancc for a particular application server. 

Note that the server load criteria values may be adjusted separately for each plication server, as desired. 
Figure 11 illustrates a partial tree view of apphcation servers in an application server cluster. InFigurc 11, asingte 
application server name, *T^ASr. is shown, along with various application con^nents that run on Ac "TlASr 
appUcation server. For exanq)lc in the embodiment shown, various Enterprise JavaBeans™ that run cm the 
"NASr servCT arc shown under the "EJB" heading. The screens shown in Figures 10 and 11 may be coqplcd so 
that the server load criteria settings adjusted on the Figure 10 screen apply to the appUcation server selected on the 
Figure 1 1 screen. 

Figure 12 illustrates a user interface screen for setting application con^onent performance criteria values, 
such as those shown in the Figure 9 table. Administrators may adjust the weight given to each factor as 
qipropriate. for each application component, by selecting the desired application conqponent similarly as described 
above. The "server load" value shown in the Figure 12 screen may be a con4X)site value conqratcd using the 
Figure 10 server load criteria values. Thus, the load balancing criteria for each particular appKcation con^xmcnt 
may be fine-tuned using a variety of factors, m order to achieve maximum performance for a particular system or 
application. The user interface may of course aUow default loadbalancmg criteria to be specified, may allow load 
balancing criteria for mdtiplc appUcation consents or multiple servers to be spc^^ 

Note that in Figures 1 0 and 12, "User-Defined Criteria** is selected in the "Load Balancing Method" field 
at the top of the screens, so that load balancing decisions arc made by the appUcation server load balancing 
services. The user interface may also allow the administrator to specily that load balancing decisions are made by 
the cUent, e.g., the web server plug-in, as described above with reference to Figures 5 and 6, by selecting a different 
option in this field. 

Refeiring again to Figure 7, the figure illustrates that the load balancing services 330 in each jqjpUcation 
server 320 may communicate with the load balancing services of otiier application servers in the chistcr in order to 
share information, such as the server load criteria and appUcation component performance criteria described abofvc. 
In one embodiment, the load balancing services communicate using standard User Datagram Protocol (UDP) 
multicasting. 

In one embodiment, intcrvab for both broadcasting and updating load b^ 
using an administrative tooL Figure 13 illustrates one embodiment of a user interface screen for setting broadcast 
and update intervals. The 'Sase Broadcast/Update Interval** field refers to a base interval at which the load 
balancing service "wakes up" to broadcast information for its respective appUcation server to the load balancmg 
services of other appUcation servers, to check to see whedier any updated information was received fiom olhcr load 
balancmg services, and to update the load balancing information with any received updates. The other mtervals 
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shown in Figiire 13 are relative to the base broadcast/update interval. For example, &e **Application Componeat 
Criteria" broadcast interval is two times the base mtcrval, so that application component performance infonnatioa 
is broadcast every other time the load balancing service wakes up. Note that performance information for a given 
application component may be exchanged only between application servers hosting that plication component, in 
5 order to avoid mmecessary network traffic. 

Figure 13 also illustrates fields for setting the broadcast interval server load infotmation, and the update 
intervals for information described above, such as the server load value, CPU load. Disk bqjut/Output, Mcmoiy 
Thiash, and Number of Requests Queued. By adjusting the various broadcast and update intervals ^jpropriatcly 
for a given application or system, the optimum balance between fresh load balancing data, server update overhead, 
10 and network traffic noay be achieved. 

The information shared among application server load balancing services may be used to dynamically 
route a request received from a client to the *'besf* application server for processing the request As discussed 
above, each chent request may reference a particular application component The decision as to which application 
server processes a request is preferably made based on the stored information regarding the particular plication 
15 conqjonent Thus, at any given time, the ''best" appUcation server for processing a request may depend on the 
particular application conc^nent that the request references, depending on how the server load criteria and 
apphcation component performance criteria are chosen, as described above. 

If the load balancing service of the application server that initially receives a request from a client 
determines that another application server is currently better able to process the request, then the request may be 
20 redirected to the other application server. As shovm in the Figure 13 user interface, administrators may specify a 
maximum number of "hops**, i.c., the maximum number of times that a request may be redirected before it is 
processed by the application server that last received the request The hop number may be updated in the request 
infonnation each tnne the request is redirected. As the processed request is passed back to the client, e.g., the web 
server plug-in, the chent may record the application server that ultimately satisfied the request, so that a similar 
25 future request would then be sent by the client directly to that appHcation server. 

'^Sticky" Load Balancing 

Administrators may mark certain appUcation conqx>nents for **sticky" load balancing, meaning that 
requests issued within the context of a particular session that reference fliat application conqwnent are all processed 

30 by the appUcation conqwucnt instance running on the same application server. Some appUcation conqionents may 
need to be marked for sticky load balancing, especially if die components rely on session information that cannot 
be distributed across appUcation servers. Such situations may arise, for exaiiQ>le, if an appUcation is originally 
written to run on one corryuter and is then ported to a distributed appUcation server cluster environment 

As an example of sticky load balancing, suppose that an appUcation conqwnent called "ShopCart** is 

35 duplicated across two appUcation servers, Server A and Server B, for load ba l a ncin g . If a first cUent, Client I 
performs a request referencing the ShopCart component, then the ShopCart instance running on cither ServCT A or 
Server B may be chosen to process the request, depending on the outcome of the load balancing decisions described 
above. Siqjpose that the Server A ShopCart instance processes the request Then, if the ShopCart component is a 
con^ionent marked as requiring sticky load balancing, any further requests issued by CUent 1 that reference the 
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SbopCart component will ako be processed by the Senrer A ShopCart component, iceardless of the other load 
balancing criteria. Requests by other cheats referencing the ShopCait component may of course be processed oa 
other servers, e.g., on Server B. but then those requests too would "stick- to the application componerrt instance 

whore they were first processed* 
5 Figure 14 illustrates an exep^plary user interface of a tool for enabling admirnstnttors to specify sticky load 

balancing for certain appUcation components. Figure 14 illustrates a group of appUcation components which, for 
example, may be displayed by navigating through a hierarchy tn^su^ IHe "Sticky LB" 

column of the user interface has a checkbox aUowing sticky load balancing to be turned on for paiticDto 
application components. 

10 Al&ough some existing appUcation server systems support sticky load balan^ 

,0 detemiine the correct application server that should receive a given sticky request is often maintained on the 
server side. TWs may result in the cUent computer sending a sticky request to a first appUcation server which then 
redirects the request to a second appUcation server .hat should process the sticky request To overcome this 
inefficiency, the cUent computer(s) may instead be operable to maintam information regarding sticky requests so 
15 that requests are sent direcdy to the conect appUcation senrer. 

In various embodiments, the appUcation server system may also enforce even distribution of sticky 
requests. As noted, the initial request to a component requiring stickiness may be made using normal load 
balancing methods, such as Aose described above. At any given time, these load balancmg methods may 
detemtine that a particular appUcation server is the "best" server to process a request. Thus, it may be possible that 
a particular appUcation server receives a huge batch of initial requests referencing sticky components. Since each 
session that sent an initial sticky request to the appUcation server is then bou.>d to that appUcation server for 
subsequent requests, the result niay be a decrease in appUcation perforinance over flie long t^ 

mis. the system may track information regarding the number of sticky requests that are currently bound 
to each application server and may force the sticky requests to be distributed roughly evenly. In one embodiment, 
administrators may assign a weight to each appUcation server, such as described above, and the sticky requests may 
be distributed in proportion to these weights. 

Graceful Distribution 

Some existing appUcation server load balancing systems use a -Wer-take^" strategy, in which all 
30 incomingrequestsatanygiventimeaieassiEnedtothecalculatedn*^ However, experience 

m the appUcation server field has shown that the result of such a strategy may be a cycUc pattern in whKl.. at a.^ 
given time, one appUcation server may be under a heavy load, while other servers are mostly idle. TOs problem 
may arise in part fiom load balancing information being shared at periodic intervals, ratto 

TUus. in various embodiments. -giaceMMoad balancing methods may be utiBze4 in wM^ 
35 appUcation server at a given time moment or interval, as defined by criteria such as described above, is assigned the 
largest number of incoming requests. whUe other appUcation servers, or a subset of die other appUcation servers, 
are stiU assigned some of the incoming requests. Such graced load bahmciag may be perfonned using any of 
various mefliods. As a simple example, a weighted random distribution algorithm may be used. For example, for a 
cluster of appUcation servers of size L, a random nmnber between 1 and L may be generated, where the generated 
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number designates the number of the application server to assign the request to, and where 1 represents the current 
'"best" application server to process the request and L represents the appUcation server at the othw end of the 
spectrmiL Thus, the random number is generated in a weighted manner, such that the probability of choosing a 
server number diminishes going from 1 to L. The resulting request distribution pattern may then appear similar to a 

5 y = 1/x graph pattern. 

This type of graceful request distribution may be applied at various levek, depending on a particular 
application or system. For exan^le, as described above, one general load balancing approach that may be used is 
to leave the distribution decision to the client, e.g., by tracking the response times as seen from each application 
server. Thus the client, e.g., the web server plug-in, may rank the application servers by their response tiiues and 

10 "gracefully" distribute requests among the application servers, thus helping to ttiaintain an even work load among 
the application servers at all times. On the other hand, if load balancing decisions are made by the load balancing 
services of the application servers themselves, as described above, then these load balancing services may employ a 
type of gracefili distribution algorithm. 

15 Request Failovcr 

As described above, requests may be brokered from a client such as a web server to an application server. 
In some instances, requests may fail, e.g., due to a lost connection between the client and the application server, an 
apphcation server failure, etc. Depending on the communication protocol used to perform the request, requests 
may time out after a certain time period. For example, a TCP/IP-based request may timeout after a conflgm^le 

20 time period. The timeout time period may or may not be configurable, depending on lire environment, such as the 
particular operating system Note that the typical default timeout period may be large, e.g. 30 minutes. If a request 
fails, e.g. due to a server power failure, other requests may be forced to wait while the requesting thread waits fat a 
response that will never come. 

Figure 15 is a flowchart diagram illustrating one embodiment of a method that may overcome this 

25 problem. In step 470, the client computer sends a request to an application server using a custom vrire-lcvcl 
communication protocol. The use of such a protocol may enable the client computer to detect and recover &om 
failed requests, as described below. Note that this custom protocol may be in^lemcnted as a protocol using various 
standard communication protocols, such as the TCP/IP j>rotocoL 

In one embodiment, each request is performed by a separate thread r unning in the client conqmter. In step 

30 472, the requesting thread sleeps, using standard operating system teclmiques. 

As shown in step 474, the requesting thread may periodically wake \sp to poll the application server for 
information regarding the status of the request The time interval for which the requesting thread sleej^ between 
performing these polling operations may be configurable by system administrators via a provided user interface. In 
one embodiment, the requesting thread may poll the application server by sending a User Datagram Protocol (UDP) 

35 message comprising information identifying the request to the application server. For exan^le, each request sent to 
the application server may comprise a request ID enabling both the client conq)uter atid the application server to 
track the request Upon receiving the UDP message, the application server is operable to use the request 
information to determine the status of the identified request and inform the requesting thread of Ac request status. 
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In step 476, the requesting thread determines whether a response to the poU message was received &om 
the application server. For exan4)le, the requesting thread may singly wait for a response for a prt-set, relatively 
short time interval. 

If a response to the poll message is received, then in step 478. the requesting thread analyzes the response 
to determine the cunent status of the request, as informed by the application server. If &e request is currently being 
processed by the application server, then the requesting thread may simply return to sleep/ as shown in step 480. 
Note that this check can thus not only detect failed requests, but may also enable the appUcation server to process 
requests that take a lot of time to process and that would result in request timeouts if standard communication 
protocols were used. 

If the request is not currently being processed by the appUcation server, dien the request failed for some 
reason, e.g.. due to a broken network connection, an appUcation server error, etc. As shown in step 482. the 
requesting thread may then re-scnd the request and then re-perform steps 472 - 488, Tbe requesting Aread may be 
operable to attempt to send the request to the same appUcation server a certain number of times before conchiding 
that requests to that appUcation server are failing for some reason and then attcn^ting to send the request to a 
different appUcation server, if the application server is part of M appUcation se^^^ 

If no response to the poU message was received in step 476, then in step 484, the requesting thread may 
send &e request to another appUcation server, if the appUcation server is part of an appUcation server cluster. 

The cUent computer preferably maintains information regarding the current state of each application server 
m the cluster. In step 486. the application server that did not reply to the polUng message may be marked as 
"offUne" so that finther requests wiU not be sent to that appUcation servCT^^^^^ 

As shown in step 488, the cUent computer may be operable to periodicaUy poU the failed appUcation 
server to determine whether the appUcation server is onUne again. For example, the cUent computer may run a 
diread tot maintains the appUcation server status information and periodically poUs the appUcation servers marked 
as being offline. If so, then the appUcation server stams infomiation may be updated so that the appUcation server 
is placed back in rotation to receive client requests. 

Class Reloading 

In various embodiments, an application server may aUow some appUcation components, such as Java 
Servlets™ and JavaServer Pages^", to be dynamically reloaded while the server is running. This enables 
administrators to make changes to an appUcation without restarting. Having to stop/restart an appUcation is. of 
course, a serious problem in many situations. As described below, administrators may specify which classes which 
are to be considered "versionable". or dynamically reloadable. 

A vcrsioning scheme is described vrith the following design points: 
. Not aU classes are versioned by default A distinction is made between "versionable** and "non-versionable" 

classes. As described above, versioning classes bydefault often suffers from various drawbacks. 
. Version all major components - If cUent's classes arc "Known" (see definition below), then versioning will 

happen automatically. 
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. User Configurable - For those client classes that are not "Known", tbe client may perform additional steps 
during deployment time to set up environmental variables. Users can then expUcitly specify additional 
application-level classes that should be venionable. , 

. Interfaces are preferably not veisioned to avoid runtime conflicts that inay be caused by dynamically updating 

interfaces. 

. nie user may designate some classes as system classes. System classes preferably are not veisioned. Certain 
classes may be designated as system classes by default 

Under the veisioning scheme described herein, a user may control class vcisionabiUty/reloadability by 
using the foUowing enviromnent entries. wMch may be implemented as registry entries. A user interface may be 
provided for managing these settings. 

. GX_ALL_VERSlONABLE 

Anon-zerovalueforthisentrycausesallclassestobeconsideredversionable. Tte default value is zero. TOs 
entry may be used for backwaid compatibihty with other systems. 

. GX_VERSIONABLE 

•nris entry comprises a semicolon-delimited list of classes that are to be considered by the system as versionable 
classes. By default, the list is empty. 

. GX_VERSIONABLE_IF_EXTENDS 

nus entry comprises a semicolon-delimited list of classes. If a user's class extends a class in dus list, then the 
user's class is considered to be versionable. TTie default class list contains the javaxservlet.GenereicServlet and 
javax servletHttpServlet classes. Users can append additional classes to this list 

• GX_VERSIONABLE_IF_IMPLEMENTS 

Ibis entry comprises a semicolon-delimited list of interfaces. If a class implements an interface in this list then the 
class is considered to be versionable. n,e default interface list contains the javax-servletServlet interface. Users 
can append additional interfaces to this list 

• GX_TASKMANAGER_PERIOD 

A timed thread wakes up periodicaUy to check for any classes that may need to be reloaded. If a user modifies a 
versionable class, the thread may instantiate a new classloader to dynamically reload the modified class. The sleep 
time period for the thread may be set by setting the vatae of the GX_TASKMANAGER_PEEIOD registry entry. 
■Die default value for the GX_TASKMANAGER_PERIOD entry is "10" seconds. 
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Known Classes . „ t_ ^ 

T^c class loader may de^e whetor a class that needs to be versioned ts known based on Us 

i^eritancc tree. Hre class loader checks for the class's super classes and implemented interlaces to determme 

whether they are in the GX_VERSIONABLE_IF_E)™S or QX_VERS10NABLE_IF_IMPLEMENT^ lists. 

respectively. If there is a match, then the derived class is considered "knovm". 

TT^ system works particularly weU in situations where an or most classes that need to be r«^ 

versioned are subclasses of a relatively small set of super classes. For example, in the case of servlets. all servlet 
classes that are versionable may be subclasses of the iavax.servletGenedcServle. or javax-servletHttpScrvlet. or 
fliey may aU implement die javax.servleLServlet interface. 

In one embodiment. JSP files are versionable by defaultlbey can easily be identified not by Aea 
inheritance, but by their ffle name cjrtension of •.jq). 

For any given chss name that the classloader is asked to check, the classloader may locate the class file m 
fl.c file system, then parse the classffle in order to identify its immediate sopen:^ 

teplemented by the class, ft is important to note that during the check, the class loader may only e™ 
classfile in the file system to detennine versionability and may not acmally load the class into the system in order 
toexamineit I^e to the cache stickiness of the mi concerning loaded classes, previous expert 
that it is usually a bad idea to load a class to detennine the ven^ionability of it Tbus the "normal- way to make 
one's class versionable is to extend/implement those classes specified in the above-^^^ 

j^,ino a Warning While Serialia np Non-versionable Passes 

One potential problem occurs when an object that is being serialized in the session/state module «fers to 
anotherobjectwhoseclassisversionable. m order to detect potential errors downstream, the session/state code can 
be modified so that when a cUent session is being seriali«d, a subclass of the stream clas, is instantiated. In th« 
subclass an inqmry is made regarding each class that is being serialized. If such a class is determined to be 

-versionable- (as defined by the above-mentioned rules), the system may issue or log a wanung. TTus detecUon 
mediod works with beans and servlets which implement the serializable interface. 

C aching . 
Any cache widnn the system which may contain versionable classes (e.g, EJB container, servlets. JSPs) may 

, ^.videaninterfecesothatadasscanbepurgedftomthecadreonaper-cl^ 

of the class to purge. Each component that pools versionable objects should provide a mechanism enabb^ 

classh.ader to infonn them that the class versions for those ol^ectshave changed,^ 

purged. For example, an appUcation server Java™ Setvlet runner or Enterprise JavaBeans™ contamer may 

iniplement such interfaces. 
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Xmplementation Details 

fa ore embodiment, there are three different class loaders working inside the system at any given time: 
. TtePrimordialGlasdoader(PCX)-usedtoloadanycoreclassesandanynati^ 



classes . 
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Engine OassLoader (EGL) - A classloadcr (™>re precisely a series of engineaassloaders) used to load ^ 
versionablc classes 

Classloaders (NVCL) - A classloader used to load all non-veisioiu*le classes. ITlcre is only 



> Non Vcisionable 

one such classloader, which is preferably never replaced. 



A loadOassO call may fas. determine whether d,e class in question is Versionable or no^ and then usc ihe 

appropriate classloader to load Ac class. 

y^^^rr*^ 1^-17- Vt^rsioninp Flowchaits . 

' Figure 16 is a flowchart diagram illustrating one embodiment of a n^thod for dynamK:aIIy discovcnng 

and reloading classes, based on the descriptions above. \. . 

in step 400 of Figure 16, a timed thread wakes up to check for modified classes. It is noted that .t may 
only be necessary to check for changes in certain classes, since cla^ are not versio,^ by defeult In one 
e^diment, the list of versionable classes may be determined once. e.g. usi.g .he med>od shown m the F.gure 17 
flowchart, and the list may be reused by the timed thread each time the thread wakes up. If an ad.— tor 
changestheversi„nabiHtysettings..belistmaybeupdated.Eachclas^ 
i. any way appropriate for a particular environment For example, the appUcation serv^ 

^ of d^e class fde when the class is first loaded and may check to determine whether the fde has sn.ce been 

"^""as shown in step 404. if no modified versionable classes are found, the thread may simply return to sleep. 
Ifoneormoremodifiedclassesarefou«d,d.ensteps406-410maybeperformedforeachmodifiedch.s. 

In stq> 406, anew classloader is instantiated. 

in step 408. the classloader instantiated in step 406 is used to reload the modified class. 
^n step 410, the modified class may be purged from any caches maintained by the appUcation server. As 
described above, any appUcation server components lb.t maintain caches may provide interfaces for purgmg a 

modified class from the cache. a 
1. is noted that Figure 1 6 represents one embodiment of a method for dynamically ^.loadmg chases, and 
various steps may be added, omitted, combined, modified, reordered 
^.ynotbenecessaiytoinstantiateanewclassloaderforeachclasstobereloaded. 

Figu«17is.flowchartdiagraminus.ratingoneembodimcntofame.hodfardete«^ 
is versionable, that is whether the class should be dynamically reloaded when modified. 

Ins.ep420ofFiguren.itisde.erminedwhe.herthecUssn_islist«^ 
(desaibed above). Ifso. then die class is versionable. ^ 
In step 422. it is determined whether one or more of the class's superelasses are hsted m the 
GX VERS10NABLE_IF_BCrENDS list (described above). If so, then the class is versionable. 

' Insu=p424 ft is'determmed whether one or more ofthe interfaces implemented by the class are li^ 
rhe GX VERSIONABLE IF IMPLEMENTS list (described above). If so, then the class is ve«.onabl. 
0.herwi^,theclassmaynotbeversionable. Modifications made to n6n-versionable classes may be ignored whde 

an application is nnming. 
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It is noted that Figure 17 represents one embodiment of a method for detennining whether a class is 
vcrsionahle, and various steps may be added, omitted, combined, modified, reordered, etc. For exanq)le. steps 420 
- 422 may be perfonncd in any order desired- 
It is noted that an application server utilizing the methods described above with reference to Figures 16 
and 17 may advantageously not consider interface class.^ to be veisionable by default, thus helping to enforce 
interface contracls between components. 

Atomic gass-Loading 

It is often desirable to update a set of classes atomically. i.e.. to have all dynamic reloading changes for 
each class in the set take effect at the same time. Without an ability to perfonn atomic class-loading, enots may 
result when classes ans dynamicany reloaded. 

Figure 18 is a flowchart diagram illustrating one embodiment of a method for performing atomic class- 
loading. As shown in step 440. an administrator may specify a set of class files to be treated as a -bundle". For 
example, the application server may provide a user interface for managing and deploying class ffles ftom a 
development enviromnent to the mntime system. This user interface may enable the administn.tor to define or edit 
a class bundle. In one embodiment, a component referred to as the "deployer manager" provides these capabiMes. 
In step 442, the administtator requests the application server to deploy (he class bmidle specified in step 

440 e.g., using die user interfece described above. 

In response to the administrator's request in step 442. the deployer manager .nay obtains a to^ 

as the "dittyClassListLock" in step 444. The dirtyaassLisOxH* may be implemented in any of various sumdard 
ways. e-E, as a semaphore. The timed thread described above that dynamically discovers and reloads modified 
vcrsionable classes may also require the dinyaassListlxxdc Urns, while the deployer manager holds the 
dirtyClassListLock, the timed thread may not proceed. 

After obtaining the dirtyClassListLock. the deployer manager copies all chiss ffles in the bundle to their 
25 appropriate nmtime locations in &e file system in step 446. 

Hic deployer manager then releases the dirtyClassUstLock in step 448. 

As shown in step 450, the timed thread can then resmne its normal check for modified classes. Thus. aU 
the new classes fiom the bundle are processed and loaded together. 

30 JavaServer Pages™ Caching 

Tto section provides an overview of JavaServer Pages™ (JSP) technology and descn^es a cachi^ 

andmethodforJSPcompoBentresponses. JavaServer Pages™ (JSP) is a Java™ platfomi technology for building 
applications creaming dynamic content such as HTML. DHIML. XHTML and XML. JavaServer Pages is a 
Standard Extension that is defined on top of the Servlet StarHlard Extension. JSP 1.0 uses the chisses ftom Java 
Scrvlet 2.1 specification. For more information on JavaServer Pages™, please refer to the JavaServer Pages™ 
Specification. Vasion LO. available from Sun Microsystems. Inc. For more information on Java scrvlets. please 
refer to the Java Servlet 2.1 Specification, available fix>m Sun Microsystems. Inc. 

A JSP component is a text^based document that describes how to process a request to create a response. 
Tie description intermixes template data with some dynamic actions and leverages on the Java™ Pbtfonn. In 
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general, a JSP component uses some data sent to the server in a client request to interact with information already 
stored on the server, and then dynamically creates some content which is then sent back to the cUcnt The content 
can be organized in some standard format, such as HlTvlL, DHTML, XHTML, XML, etc., or in some ad-hoc 
structured text format, or not at all. The following segment iUustrates a simple exan^>lc of a JSP conqponcnt 

" 5 ■ 

<litm> 

if (Calendar.getInstanceO-get{CalendarJ^_PM) ^ Calendar 

Good Morning 
<%}clse{%> 
10 GoodAftemoon 
<% ) %> 
</htmJ> 

The example above shows a response page, which is intended to display either "Good Morning" or "Good 
15 afternoon" depending on the moment when the request is received. The page itself contains several fixed tenq)latc 
text sections, and some JSP elements enclosed in **<%%>" brackets. 

A JSP conq)onent may be handled in apphcation servers by various types of JSP engines. For cxanq>le, in 
one embodiment, the Java Server process 204 shown in Figure 3 may manage or act as the JSP engine. The JSP 
engine deUvers requests from a cUent to a JSP conq)onent and responses from the JSP conqxjncnt to the cHcnt The 
20 semantic model underlying JSP conq>onents is ^t of a Servlet a JSP con^onent describes how to create a 
response object from a request object for a given protocol, possibly creating and/or using in the process some other 
objects. 

AllJSP engines must support HTTP as a protocol for requests and responses, but an engine may also 
suppon additional request/response protocols. The default request and response objects are of type 

25 Ht^ServlctRequest and HttpServletRcsponse, respectively. A JSP component may also indicate how some events 
are to be handled. In JSP 1 .0, only init and destroy events can be described: the first time a request is delivered to a 
JSP con^onent a jspInitO method, if present, will be called to prepare the page. Similarly, a JSP engine can reclaim 
&c resources used by a JSP coraponem at any time that a request is not being serviced by the JSP component by 
invoking first its jspDestroy() method; this is the same lifeK^ycle as tot o^^ 

30 JSP con5K>nents are often in^lementcd using a JSP translation phase that is done only once, foUowcd by 

some request processing phase that is done once per request The translation phase usually aeatcs a class that 
inq)lcments Ae javax.servlctServlet interface. The translation of a JSP source page into a corresponding Java 
inqjlcmentation class file by a JSP engine can occur at any time between initial deployment of the JSP component 
into the runtime environment of a JSP engine, and Ac receipt and processing of a client request for the target JSP 

35 can5>oncnt A JSP conqwnent contains some declarations, some fixed template data, some (peihaps nested) action 
instances, and some scr^ting elements, men a request is deUver^ 

create a response object that is then returned to the client Usually, the most inqwrtant part of response object is 
the result stream, 

A J^ conq)onent can create and/or access some Java objects when processing a request The JSP 
40 specification indicates that some objects are created implicitly, perhaps as a result of a directive; other objects are 
created wqjlicitly through actions; objects can al?o be created direcfly usmg scripting code, although Has is less 
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„n. createdobjec.have a scope attribute defining where 

reference is removed. ^ 

■n^e cn^ated objects «ay also be visible directly to the scripting elements through some scrrptmg-lcvel 
variablesCseeSectionl.A^.'^bjectsandVariabM.Eachactionanddeclarationdefines.^ 
5 whatobjectsitdefmes,wi.hwhatscopeattribute.andwhe.her.heyareavailableU,thes 

are always created within son. JSP cot^nent instar.ce that is responding to some request object ,SP defines 
several scopes: 

.page-Objects withpage scope areaccessible only within thepage where they^ 

.0 an object shall be released after the response is sent bac. to the client fiont the JSP conrponent or the recprcst . 
forwardedso™ewhereelse.Referencestoobjectswithpagescopearcstoredinthe^^^ 

_ ^es. - Objects wifir re^^es. scope are accessftle front pages proc.^^ 

erZ. An references to the object shaU be released after the request is ^ocessed; in particular, tf the r«i«est n 
15 fo^dedtoaresourceinthe=^eruntinre,theobjectisstinrcacha^ 
are stoied in &e request object 

«=«i„„ - Objects with session scope are accessr^le fron. pages p^ 
U.eoneinwhichtheywerecreated.ltisnotlegaltodefineanobjectwi.hsesdonscopef.r„wi^^^ 
20 not session-aware. AU references to the object shaO be relea^ after the assodated session en^ 
objectswithsessionscopearestoredinAesessionobjectassociatedwiththepageacti^^^ 

_ application - Objects with application scope arc accessible from pages processing revests that are in the s^ 
appLonastheyoneinwhichtheywerecreate.AUrererencestotheobjectshan^^^^^^^ 
35 rvironmen. reclaims the ServletContext. Objects with a^Hcation scope c« be defined (and reach.^) from 
^ are not sessior^ware. Keferenc to objects with application scope are stored in the :^bcatron 
associated with a page acdvation. A n^e should refer to a uni^^e Object at an points in the .^^^^ 

different sco^ reany should behave as a single name space. A JSP implerr^tation may or not enforce thrs rule 

explicitly due to peifonnancc reasons. 
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Fixed T emplate Data . , 
^^^h-tedataisusedtodescnT^thosepiecesthataretobeusedverbato 

^.toJSPa^on.Forex^le.iftbeJSPcomponentiscreatingapresen.ationinH^^ 

Z match «.me search <»ndi.ions. the template data may i«:l«le things lilce the <u>. <A.1>. and somethmg Ulce 

35 <li>Thcfollo(wiiigboolc., , r a\.»*u» 

TWs fixed temphte data is written (in lexical order) unch«^^ 

implicit out variable) of the response to the requesting client 
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Directives and Actions 

JSP elements can be directives or actions. Directives provide global information that is conceptually vaUd 
mdependentofanyspecificrequest receivcdby the JSP component For exan^>le, a directive can be used to 
indicate the scripting language to use in a JSP con^nent Actions may, and often will, depend on the detaUs of the 
5 specific request received by the JSP component If a JSP is inq)lemented using a conqjiler or translator, the 
directives can be seen as providing information for the compUation/translation phase, while actions are infonnation 
for the subsequent request processing phase. An action may create some objects^ 
the scripting elements through some scripting-spccific variables. 
Directive elements have a syntax of the foim 

10 <%@ directive ».%> 

There is also an alternative syntax that follows the XML syntax. 

Action elements foUow the syntax of XML elements, ie. have a start tag. a body 

<mytag attrl="attribute value** ...> 

body 
15 <ymytag> 

or an empty tag 

<mytab attrl^^'attribute value** ..i> 

A JSP element has an clement type describing its tag name, its vaUd attributes and its 
20 semantics; we refer to the type by its tag name. 

Applications and ScrvletContexts 

In JSP LO (and Servlet 2.1) an HTTP protocol application is identified by a set of (possibly disjoint) URLs 
mapped to the resources therein, JSP 1.0 does not include a mechanism to indicate that a given URL denotes a JSP 
25 component, although every JSP inq^lcmentation vwll likely have such mechanism. For example, JSPs may be 
identified by a ".jsp** file extension, hi most JSP implementations, a JSP con^onent is transparently translated into 
a Servlet class file through a process involving a Java*^ conq>iler. 

The URL set described above is associated, by the JSP engine (or Servlet runtime environment) with a 
nnique instance of a javax.servletServletContext Servlets and JSPs in the same appHcation can share this instance, 
30 and they can share global appUcation state by sharing objects via the ServletContext setAttributeQ, getAttributcQ 
and rcmovcAttributeO methods. We assume that the information that a JSP component uses directly is all 
accessible from its corresponding ServletContext 

Each cUent (connection) may be assigned a session Gavax.scrvletiittp.HttpSession) uniquely identifying it 
Servlets and JSPs in the same "appUcation" may share global s^^^^ 
35 HttpSession putValueQ. getValueO and removeValueO methods. Care must be tiikcn when shariUg/manipulating 
such state between JSPs and/or Servlets since two or more thirds of execution may be simultaneously active 
witiiin Servlets and/or JSPs, thus proper synchronization of access to such shared state is required at aU times to 
avoid unpredictable behaviors. Note tot sessions may be invalidated or expire at any time. JSPs and Servlets 
handling the same javax.scrvlctServletRequest may pass shared state using the ScrvletRequest setAttributeQ, 
•40 getAttributeO and removeAttributeO methods. 
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Translation Phase 

A typical inqjiemcntotion works by associating wife the URL denoting the JSP a JSPEngineScrvlct This 
JSPEngineServlet is responsible for determining if there already exists a JSP conqwnent inq)lcmcntation class; if 
not it will create a Servlet source description implementing the JSP conqponcnt conqjUe it into some bytecodcs and 
5 then load them via a ClassLoader instance; most likely never touching the file system. Once the JSP consent ■ 
inqilementation class is located, the JSPEngineServlet will perform the usual S^let initialization and wiU deliver 
the request it received to Ac instance. The JSPEngineServlet Servlet is instantiated in a ServlctOmtext diat 
represents the original JSP object 

10 JSP Response Caching 

This section describes how response caching may he enabled for a system iiiq)le^ 

AWiough one use of JSP is to create dynamic responses, such as dynamic web pages for diq)lay, it will be 
appreciated that response caching may be desirable in many situations- For example, data used to create a response 
may change only once an hour, and dius a response created &om the data could be cached and reused much of die 
15 time. In particular, caching may often inq>rove die performance of running composite JSPs, tot is JSP files ^iiich 
include odierJSPs. 

For each JSP consent, die criteria for reusing a cached version of die response may be set, e.g.. by 
inchiding a mcdiod call in die JSP file, such as "setCacheCritcriaO^ l^c setCacheCritcriaQ method may be 
overloaded to aUow for various arguments to be passed in. In one embodiment die sctCacheCritcriaO mcdiod 
20 conqjriscs die following signature variants: 

sctCachcOritcria(int sees) 

where die 'sees' parameter indicates die number of seconds for which die cached response should be considered 
valid. In diis variant, no odier criteria are specified. Urns, die JSP response is unconditionaUy cached. If W is 
25 set to 0, die cache may be flushed. 

setCacheCriteria(int sees, String criteria) 

where die 'sees* parameter is die same as described above, and die 'criteria' parameter specifics die criteria to use 
in detcmimingwhcdier or not die cached response noay be u^ Caching criteria are discussed 

30 in more detail below. 

setCacheCritcria(int sees, int size, String criteria) 

ifttec die 'sees' and 'criteria' parameters are die same as described above, and di^ 
azc of the buffer for die cached response. 
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CadiiDR Criteria 

The interface for calling JSPs is based on die interface javax.servletRequestDispatchcr. This interface has 
two mcdiods, forwardO and inchideQ. where die former acts like a redirect, i.e. it can be called only once per 



26 



wo 01/13228 



PCTAJS00y22063 



request, whereas the latter can be called multiple times. For exan5)le, a forward call to *fjsp» may look like: 

pubHc void servicc(HttpServletRequest req, HttpServletResponsc res) 
throws ServletExccption, lOException 



{ 



rcs.setContentType("text/html"); 
RcquestDispatchcr dispatcher = 

getServletContext0.gctRcqucstDispatcher("fo^"); 
dispatcher.forward(req, res); 



10 } 



JSP components often accept and use arguments tfiemsclves. Arguments to the JSP file can be passed as part of flic 
IJia of the me, or in attn^utcs using ServletRcqucstsctAttnl^ 
to set caching criteria and to check whether a cached response can be used to sa^ 
15 For exangjle, in an include caU to Xjsp\ arguments 'age' and 'occupation'^ 

pubhc void service(Ht^ServlctRequest req, HttpServletResponsc res) 
throws ScrvlctException, lOExccption 

20 ^ res.setContentTypc(*'text/htnil"); 

RequcstDispatcher dispatcher = 

gctServletContext0.gctRcqucstDispatchcr(''fjsp?agc=42"); 
rcq^tAttribute("occupation'*,"doctor"); 
dispatcher.inchidc(req, res); 

25 } 

Wfein the Ijsp component, a setCacheCriteriaO statement nmy then set 

vahies of the *age' and 'occupation' atBumcnts, For cxaiaplc, tbe fjsp conqwncnt may include the statement: 

30 <%setCadicCriteria(3600,"age>40&occupation==doctor^^ 

to indicate that the response should be cached with an expiration time of 3600 seconds, and that die response may 
be used to satisfy any requests to run the f jsp consent with an 'age' argument vahic of greater dian 40 and an 

'occupation' argument value of "doctor". 
35 Of course, the JSP con^oncntrnay contain numerous sctCacheCrite^ 

Ac JSP me, e.g. at dififerent branches within an 'if statement, each of 

Depending on fee arguments passed in to Ae JSP and other dynamic conditions, a particular set of caching critciia 
may then be set for the response currently being generated. 

In cxanq)le above, the dispatcher may use the vahies of the 'age* and •occiq)ation' arguments to 
40 determine vAeflier any cached JSP responses can be used to satisfy a request instead of rc-runnmg the JSP and re- 
generating a response ftom it For cxaiiq)le, a request to f.jsp appearing as: 

res.sctContcntType("text/html'*); 
RequestDispatcher dispatcher = 
45 gctServletContcxt0.getRequestDispatcher("fjsp?age=39&occupation=^ 

dispatcher.forward(req, res); 
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would not be satisfied by a response previously generated from the f jsp JSP which had set its caching criteria with 
the statement: 

<% setCacheCriteria (3600, "age>40 & occupation=doctor*^; %> 

because the age argument is not within the range specified as valid for this cached response. However, this same 
request may be satisfied by a response previously generated from the f.jsp JSP which had set its caching criteria 
with the statement: 

10 <% setCacheCriteria (3600, "age>35 & occupation==doctor^; %> 

Hence the cache may be checked before running a JSP, and if a vahd cached response is found, then die dispatcher 
may return the response immediately, 

15 A cached JSP response may be stored in various ways. In one embodiment, a response is stored as a byte 

array (byteQ in Java). Each cached response may have an associated criteria set stored, indicating when the 
response is valid. The criteria may include an expiration time, e,g. a time in seconds to consider the cached 
response valid After this expiration time passes, the response may be removed from the cache. The criteria may 
also include a set of constraints, where each constraint specifies a variable and indicates the valid values which the 

20 variable value must match in order to satisfy the cache criteria. As described above, a JSP response may set diese 
cache criteria progranjimtically using a setCacheCritcriaO statement For example* the SetCacheCriteria (3600, 
"agc>35 & occupation=doctor") statement appearing above specifies an expiration time of 3600 seconds and a 
constraint set widi two constraints: 

25 *age*>35and 

'occupation' = "doctor" 

In various embodiments, different types of constraints may be specified, including the following types of 
constraints: 

30 

_x (e.g., SetCacheCriteria (3600, "x')) 

meaning diat *x' rnust be present either as a parameter or an attribute. 

— x = vl |y2|... |vk (e.g„ SetCacheCriteria (3600, •*x^octor|nurse'0) 

35 meaning that *x* must match one of the strings listed. For each string, a regular expression may be used, where *x' 
is said to match flic string if it meets the regular expression criteria given, 

-x = low-high (e.g., SetCacheCriteria (3600, "x=20- 50**)) 

ineaning that 'x* must match a value in the range of low <== x <= high. 



28 



wo 01/13228 



PCT/US(K)/22063 



Various other types of constraints may also be specified, such as the Bse of mathematical "greater than/less than" 
symbok, etc. for cnsurinE that an argument falls within a certain range. Also, constraints may be specified based 
on dynamic user session data, such as the euirent value of a user's shopping cart, user demogr^hic information, 
etc. 

H pure 19 - Flowchart 

Figure 19 is a flowchart diagram illustrating one embodiment of a mediod for enabling JSP response 
caching, based on the above description. In one embodiment, the JSP engine manages the process illustrated in 
Figure 19. 

In step 600 a request referencing a JSP component is received. The request may, for exanqile, have an 
associated URL that references a JSP. The JSP engine may receive the request from another seivicc or component 
running on the appUcation server or directly from a cUcnt coiiqjuter. 

In step 602 the JSP response cache is checked to determine whether a response in the cache satisfies the 
request The JSP response cache may be inqalemented in any of various ways, and responses and dieir associated 
criteria sets may be represented and stored in &e cache in any of various ways. As noted above, in one 
embodiment, a response is stored as a byte array. 

As described above, the infonnatioa received along with ttie JSP request may include various attributes, 
such as variable name value pairs. In step 602, these attributes may be conqiaied against the criteria set for each 
cached response. The con^ons may be performed in various ways, depending on what types of matching 
criteria are supported in a particular embodiment and how the criteria are stored. Tlic JSP response cache is 
preferably organized to enable an efficient criteria-matching algorithm. For exan^lc, the cache may be organized 
based on session context such as user ID or role, security context, etc. 

In step 604 it is determined whether a matching cached response was found in step 602. If so, then in step 
606 the cached response is immediately returned without running the referenced JSP. For exan^le, if responses arc 
stored as byte arrays, then the byte array corresponding to the response whose criteria set matched Ae request 
attributes may be retrieved and streamed back- 

If no matching cached response was found, then in step 608 the referenced JSP maybe called. Ibe JSP 
engine then executes the JSP, using the attributes included in the request As described above, depending on tfic 
dynamic conditions of execution, different SetCacheCriteriaQ mediod calls with different arguments may be 
encountered during the JSP execution. 

In step 610 it is determined whether the JSP response should be cached. For example, if no 
SetCacheCriteriaQ mediod calls were encountered during the execution of the JSP, then tiic response may not be 
cached. Also, in various embodiments, the appHcation server may enable administrators to utilize a user interfece 
to specify for which appUcation server components the output should be cached. This information may also be 
checked in step 610. 

If the JSP rc^onse should not be cached, dien the response may simply be returned in step 616, eg., by 

streaming back the response. 

If the JSP response should be cached, then in step 6^ a response entry to represent the response may be 
created, and in step 614 the JSP response may be stored in the response entry. As noted above, response entries 
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may be iinplemented in any of various ways. As shown in step 612, the appropriate criteria set, as defined by the 
arguments of the SetCacheCriteriaO method calls encountered during the JSP execution may be associated with tiie 
response entry. Note that, if multiple SetCacheCriteriaQ method calls are encountered, then multiple response 
entries corresponding to the method calls may be created- 

5 Instep 616 the JSP response is then returned. 

It is noted that Figure 19 represents one embodiment of a method for enabling JSP response caching, and 
various steps may be added, omitted, combined, modified, reordered, etc. For example, in one embodiment, a step 
may be added so that the JSP file referenced by the request is checked on the file system to determine whether tfie 
file has been modified since the JSP was loaded or since the associated responses were cached. If so, the associated 

10 responses may be flushed fitjm the cache, and the JSP may be reloaded and called. 

Composite JSPs 

Wifli the support described above, conqwsite JSPs, that is JSP files which include other JSPs, can be 
efficiently in^lcmcnted. There may be one top-level fi:ame, emitted cither fiom a servlct or firom a JSP, which 
15 issues one or several RequestDispatcher.include calls for other JSP files. Each of Ihc included JSP files may 
generate response content Some of these JSP files may akeady have associated responses cached, and others may 
not For each cached response time, the associated eviration time may vary. 



20 
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For example, here is a *conqx)se.jsp' JSP listing: 



<% setCacheCritcria(l); %> 
<HTML> 
<HEAD> 
<rni£>conq>osc (JSP)</TTrLE> 
25 </HEAD> 
<BODY> 

<H2>Channel 1</H2> 
<% 

RequestDispatcher disp = 
30 getScrvletContext0.getRequestDispatchcr("cl.jsp"); 

disp.include(request, response); 
%> 

<H2>Channcl2<yH2> 
<% 

35 disp = getScrvlctContext0.getRequestDispatchcrC*c2.jsp"); 
di^.inciude(Tequest, response); 
%> 

</BODY> 
</HTML> 



where 'cl.jsp' appears as: 



<% setCachcCriteria(10); %> 
<u> 
45 <Ji?>Today,.. 



30 



wo 01/13228 



PGT/USOO/22063 



and *c2.jsp' appears as: 

5 <%setCachcCritcria(2,V);%> 
<u> 

<K>TomoTTOw ... 



10 



35 



<Ail> 

Note that neither *c 1 jsp* nor ^2 jsp' emits con^lete HTML pages, but rather snippets Uiacof, and that each file has 
its own caching criteria. 



A helper function for inchiding URIs may be provided, so that, for exan^le, the above-listed 'conq)osc.jsp* file 
15 may appcaras: 

<% setCachcCriteria(i); %> 

<HTML> 

<HEAD> 

20 <aTIl^ompose(JSP)</ITrLE> 
</HEAD> 
<BODY> 

<I2>Channel 1</H2> 
<% 

25 includcURI("cl.jsp",rcquest,responsc); 
%> 

<I2>Channel 2</H2> 
<% 

includcURI("c2 jsp",requcst, response); 

30 %> 

<mODY> 
</HTML> 



instead of as the listing shown above. 
Events 



In various embodiments of application servers, developers can create and use named cvcnte. Hie torn 
event is widely used to refer to user interface actions, such as mouse cli^ However, the events 

described in tiiis section are not user interface events. Rafher, an event is a named action or set of actions may 
40 be registered with Ac ^Ucation server. The evem may be triggered either at a specified tnne or may be activated 
fiom apphcation code at runtime. For cxan^le, the executive server process 202 in fte application server 200 of 
Figure 3 may be responsible for triggering scheduled events. Typical uses for events include periodic badoq^s. 
reconciling accounts at the end of Ae business day, or sending alert messages. For cxanqjle, one use of an event 
may be to send an emaU to alert a conq>any's buyer when inventory levels drop below a certain IcveL The 
45 application server preferably implements the event service to be a high-performance service that scales well for a 
large number of events. 
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Each event may have a name, possibly a timer, and one or more associated actions, and possibly associated 
attributes. For events with multiple actions, an execution order for the actions may be ^Ksdfied. The actions can 
be configmred to execute either concurrently or serially. Possible actions include nmning an application software 
com^jonent or module such as a Java"™ Servlet, sending an email, etc. Administrators can configure events to occur 
5 at specific times or at intervals, such as every hour or once a week. Events may also be triggered programmatically 
by calling the event by name from code, such as a Java^ Servlet, EJB, etc., or a C/C-H- component, etc As noted 
above, Java and C/C++ conqjonents may be handled by separate processes engines. When an event's timer goes 
off or it is called from code, the associated actions occur. Events may be triggered eidbcr synchronously at a 
synchronously. 

10 It is noted that, since events may be triggered programmatically, portions of qjplication logic may be 

encapsulated as events, for exarrq>le by triggering an event which causes a Servlet or oihcr software con^poncnt to 
execute. The software con^nent may of course be coded without any knowledge that the cozi^ncnt will be 
called as a result of triggering an event Also, note that if components are called as a result of triggering an event, 
the component may run from any server. Calling a component as a result of triggering an event may thus 

15 advantageously result in the same benefits described above that the application server provides for con^>onents 
called in other ways, e.g., load balancing, result-caching, etc. 

An input list referred to as a ValList may be passed to triggered events. There may be a separation 
between Attributes and Actions of an event This ValList conq^rises entries describing Attributes. Each action of 
an event is represented by a separate ValList The event API may provide methods to get/set attributes and also 

20 mediods to add/delete/eninnerate actions. 

As described above, mult^le application servers may be grouped in a cluster. In one embodiment of ^ 
event service, events, or a particular event, may be configured to have a chister-wide scope, so that they do not need 
to be defined and registered for every server in the cluster that needs them. Each event may have associated 
attributes specifying which application server the event should run on, load balancing criteria, etc. Events arc 

25 preferably stored persistently, e.g. in a registry or a databasc- 

In one embodiment, events may be registered by any application server engine and triggered by any 
application server engine. Events may be registered on multiple application servers. In one embodiment, event 
operations such as registration, adding actions, getting attributes, etc. may occur on multiple servers in a single 
operation, ic. the event API may support event management across multiple application servers. For exarr^le, an 

30 event may be created from one application server and then called from another application server. 

Event API 

•Jbis section discusses one embodiment of an API for managing and nsing events. 

35 To create a new event, use the following procedure: 

1, Obtain the event manager object by calling getAppEvent(). Forcxarnple: 
lAppEvent eventMgr gctAppEventO; 
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2. Specify the characteristics of the new event by setting up an IValList object with a set of vahies, each one being 
one characteristic of the event The values required in this object vary depending on whetiier the event's action is to 
run an application component, send an email, etc. 

3. Inform die application server of the new event by calling registerEvcnt( ). 
For example, the following code sets up an event to send email: 

IValList evcntOutput; 

IValList evcntlnput2 = GX^CreateValListQ; 

String cventName2 "TleportEvcnf*; 

// Add the ReportAgcnt appcvent name to the valKst 

evcntInput2.setValStrmg(GX_AE_RE_KJET_NAME.GXj\E_RE_K^ 

eventName2); 

// Set the appcvcnt state to be enabled 

cvcnthq5ut2,setValInt(GX_AE„RE_KEY_STAmGX_AE„RE_KEY_STATC^ 
GX_AE_RE_ESJFLAG.GX_AEJIE_EVENT_ENABLED); 
// Set the appcvcnt time to be 06:00:00 hrs everyday 
cventInput2.setValString(GX^AEJREj:Ey_TIME.GX_A^^ 

"6:0:0 */*/*"); 

// Set the appcvent action to send e-mail to 
// teport@acme.com 

evcnthipua.setValString(GX_AE_RE_KEY_MTO.GX_AE_REj;:EY_^^ 
"repOTtQacmccom^; 

// The content of die e-mail is in /tmp/rcport-file 
cvcntInput2.setValString( 

GXJVE_RE_KEY_MFILE.GX_AE_REJK^_NIFILE. 
•'/tnqx/rcport-filc"); 

// The e-rnail host running the SMTP server is mailsvr 
cvctttInpui2.setValStnng( 

GX>E„RE„KEY_NfflOST.GX_AE_RE_KEy_MHOST, 
"mailsvr.acmc.com'O; 

//The sender's c-mail address is admin@acme.com 
eventIr^mt2j5etValString( 

GX_AEJUE_KEY_SADDR.GXlAE_RE_KEY_SADDR, 

*admin@acmc.com'^; 

// Register die event 

if (cventMgrjegistcrEvent(evcntName2, eventhq>ut2) 
NGXE.SUCCESS) 
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nrtura strcamRcsult("Can not register ReportEveat<br^ 

Triggering an existing event 

Typically, an event is triggered at time intervals which you specify when you create the event You can 
5 also trigger the event at any tune from code. The event still occurs at its timed intervals also. Those events that do 
not have a timer are triggered only when called from code. 

To trigger an event 

1 . Obtain the event manager object by calling gctAppEvcnt( ), For exan^ile: 
10 lAppEvent eventMgr =^ getAppEventO; 

2. If you want to chaise any of the characteristics of the event before lunning it, set up an IValList object witfi the 
desired characteristics. Use die same techniques as you did when setting up the event, but tnchide only those 
characteristics you want to override. For exaiiq>le: 

15 IValList newProps==GX.CreateValListO; 

ncwProps.setValString(GX_AE„RE_KEY_NREQ.GX_AE_RE_KEY_Nm^ 

"RunRcportV2"); 

3. To trigger the event, call setEvent( ). For example: 
20 evcntMgr.sctEvent("R]eportEvent",0,ncwProps); 

Deleting an event 

Delete an event when the event and its actions are not meaningful anymore, or if you want to use Ike event 
25 only during the lifetime of an application con^onentexecution- 

To delete an event 

1. Obtain the event manager object by calling getAppEvcnt(). For example: 
L^Evcnt cvcntMgr gctAppEvcntO; 

30 

2. To delete the event permanently, call deletcEvent(). For example: 
cvcntMgr,dclcteEvcnt('*RcportEvcnt"); 

35 Ten^xMtarQy disabling an cvciit 

Disable an event if you don*t want it to be triggered during a temporary period. For exanqile, you might 
not want to generate reports during a company holiday . 



34 



wo 01/13228 PCr/USOO/22063 

To disable and enable an event 

L Obtain the event manager object by calling EetAppEvcnt( ). For exan^^ 
lAppEvent eventMgr = getAppEventO; 

5 2. to stop the event fmm running tcnqjonirily, call disableEvcnt( ). For exanq)le: 
evcntMgr.disableEvent('T[^eportEvcnt"); 

3 When you want the event to be available again, call enableEvent( ), For exanq)le: 
eventMgr.enablcEventC'ReportEvent"); 



10 
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Getting information about events 

To get fafonmtion about a particular event. caU quetyEvenK ). Tlas method returns the IVaJUst object 
tot contains &e characteristics of the event. To get complete details about aU the cnnently defined events, first 
call enumEventsC ). TTiis method returns the IValList objects of all the events known to the appUcation server. Then 
call cnumNext( ) to step flxroueh the IValList objects returned by enumEvents( ). Hie enumEvents( ) and 
queryEvent( )methods are defined in the lAppEvent interface. He enmriNext( ) method is defined in the 
lEnumObject interface. 
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Exaiiq)lc; 

The following code generates a report of all registered events. 

// Open /tmp/report-file for writing the report 

FileOutputStream outFile = null; 
5 outFile = newFileGutputStream("/tmp/rcport-file"); 

ObjectOutputStrcam p = null; 

p = new ObjcctOutputStream(outFile); 

// get appevent manager 

lAppEvent appEvent = getAppEventO; 
10 // Get Ae Enumeration object containing ValLists for all 

// tbc registered events 

ffinumObject enumObj = sqipEvcntemunEventsO; 
// Retrieve the coimt of registered appcvcnts 

int count = enumObj.enmnCountO; 
15 p.writeObject("Numbcr of Registered Events:"); 

p.writeInt(count); 
cnumObj.enumReset(0); 
while (coimt>0){ 

lObject vListObj = enumObj.cnimiNcxtO; 
20 IValList vUst = (IValList)vListObj; 
String name - 

vListgetValString(GX_AE,RE_KEY_NAME.GXjyE_RE_KFir_^ 

p.writeObject(*W)efimtions for AppEvent named **); 

p,writeObject(namc); 

25 p.writeObjectC*\n"); 

// Reset the next item to retrieve from ValList to be 

// flic first one 

vListresetPositionOy/ Iterate through aU the items in the vallist and 
//print them 

30 while ((name ^ vUstgetNextKcyO) N nuU) { 
GXVALval; 

val - vLisLgetVaIByRcf(name); 
p.writcObjcct("\n\t"); 
p.writeObjcct(namc); 
35 p.writeObjcct("-"); 

p.writcObject(val.toStringO); 
. " ■ } 
} 
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Exanqple interface for event API: 

interface IGXAppEventMgr { 
HRESULT CreateEvent( 
5 [in]LPSTRpEvcntName, 

[out] IGXAppEventObj ♦*appeventObj 

); 

HRESULT RegisterEvent( 

[in] IGXAppEventObj* appEventObj 

10 ); 

HRESULT GetEvent( 

[in] LPSTR pEventName, 

[out] IGXAppEventObj ♦♦pAppEvent 

15 ); 

HRESULT TriggerEvent( 
[in] LPSTR pEventNamc, 
[in] iGXValList ♦pInValList, 
20 [in] BOOL syncFlag 

); 

HRESULT EnableEvcnt( 
[in] LPSTR pEventName 

25 ); 

HRESULT DisableEvent( 
[in] LPSTR pEventName 

); 

30 

HRESULT DeIeteEvcnt( 
[in] LPSTR pEventName 

); 

35 HRESULT EnumEvcnts( 

[out] IGXEnumObject ♦*ppEvents 

); 

} 

40 Descriptions: 



OeateEvent 

pEventName: name of the event to be registered. 
appeventObj: pointer to returned appevent object 
45 CreateEvent creates a empty appevent object Attributes and Actions can be set on the returned appeventObj, and 
then registered with AppEvcnMgr using RcgisterEvcnt Note that changes to app^^ 

is registered witii die Manager. 



RcgisterEvcnt 

50 appeventObj: pointer to appevent object to is to be registered. 
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Registers a appevent object whose attributes and actions have been setup. AU changes to appEventObj arc 
committed to the sersrer, and the regisdy . If an appevent object aheady exists for the given name, then that object is 
deleted and this nev/ object will take its place. 

5 GetEvcnt 

pEventNamc: name of the event 

appeventObj: pointer to returned appevent object 

GctEvent retrieves a appevent object for a given event name, 

10 TriggerEvent 

pEventName: name of the event to be triggered. 

pValList ii^ut ValList that is passed to Actions. 

syncFlag: boolean flag to denote if event is to be triggered synchronously. 

Triggers a specified appevent A copy of pInValList is passed as ii^ut to all actions registered with the appevent 



15 
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25 



If the Action is an applogic, then pInValList is passed as input to that applogic. 
If the action is a mail, then pInValList is curreuUy singly ignored 

If the action is a Scrvlet, then the entries of the input vallist are available as attributes of ServletRcquest object that 
is passed to the Scrvlet 

If syncFlag is FALSE, then the event is triggered, and the call immediately returns without waiting for the actions 
to complete execution. If the flag is TRUE, then this caU blocks until the event is triggered and all actions arc 
executed. 

Actions are triggered exactly in the order they have been added to the appevent object 



EnableEvent 

pEvcntNamc: name of the event 
Enables a appevent 

DisableEvcnt 

pEventNamc: name of the event 
Disables a appevent 



35 DeleteEvcnt 

pEventNamc: name of the event 

Delete a appevent from the system and the registry. 

EnumEvcnts 



30 
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ppEvents: pointer to returned enura object 

Enumerates all appcvents that are registered with the server. Each element of the retiuned Enum object contains a 
appevent object (of type IGXAppEventObj). 

5 interface IGXAppEventObj { 

HRESULT GctNamc( 

[out, si2e_is(nName)] LPSTR pNamc, 
[in, default„value(256)] ULONG nNanie 

10 ); 

HRESULT SetAttributes( 
[in] IGXValList* attrList 

" ); 

15 HRESULT GetAttributes( 

[out] IGXValList** attrList 

); 

HRESULT AddAction( 
20 [in] IGXValList* action 

); 

HRESULT DeleteActions( 

); 

25 

HRESULT EnuniActions( 

[out] IGXEnumObjcct** actions 

30 }; 

GctName 

pName: pointer to a input buffer. 
liName: size of ii^)ut buffer. 
35 Gets the name of the appevent The name is set when tiie object is created with CreateEvcntO* 

SetAttributes 

attrList ii^ut attribute vallist 

Sets the attribute ValList of the appevent. Note that changes to an appevent object are not annmitted until it is 
40 registered with the AppEvcntMgTi 

GetAttributes 

attrList pointer to returned attribute vallist 
Gets die attribute vallist of a appevent 

45 

AddAction 

action: input action vallist 
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AddAction appends an action to a ordered list of actions. When an event is triggered, the actions are executed 
exactly in the order they have been added. Vallist entries describe the action being added, and vaiy from one type 
to another. 

5 Delete Actions 

Delete all actions added to tibis appevent object 

Fnum Actions 

actions: pointer to returned enum object 
10 Enumerates actions added to this appevent object Each entry in the returned enum object is a action vallist of type 
IGXValList 

San5)le portion of registry: 

6 EVENTS2 0 

15 7 tstEvl 0 

0 Enable 4 1 

0 ActionMode 4 1 

0 Time 1 *:0,10^O,3O,40,50:0'»'/*/* 

0 ActionCount 4 4 

20 8 1 0 

0 Sequence 4 1 

0 NewReq 1 GinDGX-{754CE8F7-8B7A-153F-C38B-0800207B8777} 

8 2 0 

0 Sequence 4 2 

25 0 ScrvletReq 1 HeUoWorldServlet?argl=^all&arg:u2=valu2 

8 3 0 

0 Sequence 4 3 

0 MdlFilc 1 /u/rchinta/appcvjnail 

0 SenderAddr 1 rchinta 

30 0 MailHost 1 nsmail-2 

0 Tolist 1 rchinta 

8 4 0 

0 Sequence 4 4 

0 NewRcq 1 GUIDGX-{754CE8F7-8B7A^153F-C38B-0800207B8777} 

35 7 tstEv2 0 

0 Enable 4 1 

0 Time 1 ♦:8K) ♦/♦/♦ 

0 ActionCount 4 1 

8 1 0 

40 0 Sequence 4 1 

0 NewRcq 1 GLnDGX-{754CE8F7-8B7A-153F-<38B-0800207B8777)?pl=heUo0 



45 Request Steps 

In various embodiments, an application server may handle requests using a workflow model of defining a 
series of steps for each type of request As a siirq)le example, consider the application server architecture shown in 
FiguiB 3, in which a request of four steps is processed. The first step may be to detemaine the appropriate entity to 
* handle the request For example, the executive server 202 may broker a request to the Java server 204 if the request 

40 
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references a Java™ component, or to the aC++ server 206 if the request references a component, etc. At 
another level, the Java server 204 may determine which Java™ conqwnent should handle a request Thus, request 
steps inay have different meanings in different contexts. 

Continuing the exanqjle, the second step may be to load tiie entity found in step 1 above. For exan^le, the 
5 Java server 204 engine may instantiate the appropriate Java™ object Some steps may not apply in certain contexts. 
For example, step 2 may not apply to an executive server-level request, since the appropriate server pr process to 
hand off a request to is probably already running. 

The third step may be to "run*' the entity using the request context, e.g. request parametcra. For cxanq)le, 
this run step for the executive server may mean to send the request data to the Java server and await Ac results. For 
10 the Java server, this run step may mean to run the Java™ component on the Java™ virtual machine. 

The fourth step may be to stream back Ac results generated in the fliird step to the originating leqoestox. 
Different step lists may be defined for each type of request For example, Ac step list for a request 
referencing an Enteiprise JavaBean™ may be different fixrai ihe step list for a request referencing a Java™ Scrvlet 
This method of reprcsentmg requests as a scries of steps provides advantages such as the flexibility of 
1 5 weaving steps in any way desired for a given level. Also, steps may be easily added into the step hst For exanq)le, 
while traditional programming models may require code to be recompiled or reloaded in order to alter request 
logic, the step model allows a new step to simply be added. 

Request Qucueing 

20 Each request received from clients such as web servers may be packaged in a data packet having a 

particular format According to this format, a field in the data packet may specify a suh-protocoL This sub- 
protocol may specify which step list to use for tiic request 

A request manager service and queue and thread managers arc discussed above widi reference to Figure 4. 
If a request needs to be queued, for exanqjlc if all the request-handhng threads are busy processing requests, then 

25 the request may be placed into different queues based on the type of request A thread pool may be associated with 
each request queue. Threads in different thread pools may have different characteristics. For cxanqilc, requests 
requiring XA behavior, as defined by the XA standard protocol, may be placed in a request queue that has an 
associated thread pool comprising XA-enabled threads. If at some pomt while a request is being processed it is 
determined that the request needs to be handled by a dififercnt dircad, then the request may be re-queued in the 

30 appropriate queue. For exanq)le, if a non-XA-cnabled duead is processing a request, and the application logic 
determines that the request now requires XA behavior, then the request may be requeued into a request queue with 
an associated thread pool conqirising XA-enabled threads. Optimizations arc preferably performed so that the 
request docs not have to repeat the entire oveAead of being taken from the networic stack, unmarshaied, etc, 

35 Logging Facility 

In various embodiments, the application server may provide a robust, flexible logging facihty, as described 
m this section. When logging is enabled, messages generated by application-level and system-level services may 
be logged. These messages describe the events that occur while a service or application is running. For example, 
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each time the server conmnmicates with a database, the logging facility may record the resulting messages 
generated by a database access service. 

Determining Types of Messages to Log 
5 Various types of messages may be logged. In one embodiment, messages are categorized into the following types: 

• Information message. Describes the processing of a request or normal service activity, such as a status update, 

• Warning message. Describes a non-critical problem that might be an indication to a larger problem. For 
exainple, when a service is unable to comiect to a process, a wainiiig iiiessage rimy be logged 

10 • Error message. Describes a critical faihire of a service, from which recovery is not likely. For example, when 
a service cncoxmtcrs a critical problem, such as a pipe closure. 

A user interface may be provided to manage message logging, e,g..enabKng/disabling logging, spcci^ring 
the types of messages to log, etc. An exan^le of a user interface to manage message logging is shown in Figure 20. 
15 In Figure 20, the Maximum Entries field specifies the maximum number of entries that can exist before data is 
written to the log. The Write Interval field specifics the amount of time (in seconds) that elapses before data is 
written to the log. The Message Type field specifies which types of messages should be logged (informational 
messages, warnings, and/or errors.) 

20 Lo g Message Format 

In one embodiment, log messages has the following four components: 

• date and time the message was created 

. message type, such as information, warning, or error 

• service or application component ID generating message 

25 •message text 

Lo gging Destination 

The logging service can preferably be configured to record server and application messages in any or all of the 
following destinations: 

30 • Process consoles. By default, the process consoles may display log messages as they arc generated. If logging 
is enabled and the server is enabled for automatic startup (UNDQ or interaction widi the desktc^ (NT), the 
consoles open and display (he log messages. This feature can be disbaled by deselecting the Log to Console 
checkbox. 

35 • Application log. The default appKcation log file. For Windows NT, this may be viewable througjl the Event 
Viewer. This is the dcfeult Provides a more conqjrehensive record of the server and application error 
messages. Warning and infomiation messages are not logged to the application log. All messages arc sorted by 
their timestamp. 
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• ASCn text file. An ASCH text file, which the nscr can create and specify. Used for a more pcimanent record 
of the server and appUcation messages. All messages are sorted by their timestanq>. 

. Database table. A database table which can be created and specified. This may be the most versatile logging 
destination and can be used when it is desired to sort, group, and create reports of the logged messagi^. 

In one embodiment, the server may use a log buffer to store messages before they arc written to the 
appUcation log, an ASCD file, and/or database logs. This buffer optimizes the performance of die i^licatian server 
by limiting die use of resources to continually update a log. The. buffer is written to the destination when eidier die 
buffer interval times out or die number of entries in die buffer exceeds die maximum number allowed 

The foUowing messages sent to an ASCH text ffle iDustrate cxenq)lary formats of text messages: 
[11/18/97 11:11:12:0] info (1): GMS-017: server shutdown (host 
OxcOaSOlae, port 10818, group 'MIS') -updated host database ^ 

[1 1/18/97 11:11:18:2] warning (1): GMS-019: dijqjHcate server (host 

0xcOa8017f; port 10818) recognized, please contact sales representative for additional licenses 
LoRRing to a Database 

If messages are to be logged to a database, an event log database table may be created. Figure 21 ilhistratcs an 
cxen^lary type of database table for logging messages. On some systems, suppUcd scripis may be used for 
automaticaUy setting up database tables. The appUcation server logging service may m^ die message elements to 
the database fields hsted in die table. 

File Rotation 

As shown in Figure 20, die appUcation server logging facility may be configured to rotate ASCII log files 
at scheduled time intervals. When a log file is rotated, die existing log file may be closed and moved to an archive 
location, and a new log file may be created for recording further log events. Since log files are stan^ widi die 
time and date diey arc created, log file rotation helps organize log files into manageable units. Tlic times at which 
die log files should be rotated may be specified using a regular time interval, as iUustratcd in Figure 20, or using a 
string expression, e.g.. by typing a string into die field shown. In one embodiment, a string expression should be of 

die fonnat 
hhOTm:ss W/DD/MM 
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10 



where the following table explains each element of the expression: 

Element Explanation Possible Values 

hh hour of the day 0-23 

mm minute 0-59 

ss seconds 0-59 

W dayofttieweck 0 - 6 (0 for Sunday) 

DD day of the month 1-31 

MM nionth 1-12 



Each of these fields tnay be either an asterisk or a list of elements separated by commas. An clement is 
either a number or two numbers separated by a minus sign, indicating an inclusive range. An asterisk specifies all 
legal values for that field. For exan^le, the expression: 
2,5-7:0:0 5/*/* 

15 specifies that logging should be rotated at 2:00am, 5:00am, 6:00am and 7:00am every Friday, The specification of 
days can be made by two fields: day of the month (DD) and day of the week (W). If both are specified, then both 
may take effect For example, the cxprcssiotu 
1:0:0 1/15/* 

specifies that logging to a new file starts at 1 :00am every Monday, as well as on the ftiteeutfa of each month. To 
20 specify days by only one field, the other field may be set to ***". 

In one embodiment, the following environment entries, which may be implemented as registry entries, arc provided 
to manage log file rotation. A user interface such as shown in Figure 20 may be provided to set these entries. 

• EnableRotation: Log file rotation wiU be enabled when set to "1", or disabled when set to **0**. By de£iult» log 
25 file rotation is disabled. 

• RotateTime: An expression string denoting the time at which the log file is to be rotated. 

• TextPath: In one embodiment, when log file rotation is not enabled, the name of each log file is based on the 
value of the TextPath entry, plus the process ID of the logging process. When log file rotation is enabled, the 
name of each log file is based on the value of the TextPath entry, plus the process ID, plus the tinK at which 

30 the file is created A file name may be of the format <TcxtPath?*_<process-id>_<timc-crcatcd>, where 

<TcxtPath> is the value of the TextPath entry, <piocess-id> is the id of the logging process, and <time- 
created> is the time at which logging to the file started. 

Logging Web Server Requests 

35 The application server may be configured to log web server requests. For example, a web server plug-in 

such as shown in Figure 4 may send requests to the application server ^niiere they are processed. By logging web 
server requests, request patteriis and other iinportant request information ixiay be tracked 

Web server requests may include HTTP requests. A web server HTTP request may be divided into 
• standardized HTTP variables used by the web server to manage requests. The application server may include titese 
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or a subset of these HTTP variables to be logged Variables may be added to the list if additional log information is 
desired In one embodiment, each HTTP variable is mapped to a field name in a database table. Figure 22 
iUustrates an cxenq>lary type of database table for logging web server requests. On some systems, supplied scripts 
may be used for automatically setting up such a tabic. 
5 Note that Figure 22 illustrates a field name of *1ogtime" in the database table. The application server 

logging service may record the time that the message is created in the logtime database field Note that database 
field name may be renamed The fields from the database table may be automaticaUy mapped to web server 
variables in the registry. 

10 Out of Storage Space Condition 

One problem that is not handled well, or not handled at all, by many application server logging facihtics is 
an out-of-storage-space condition, such as an out-of-disk-space condition. Smcc many other logging feciMcs do 
not handle an out-of-storage-space condition gracefuUy, Ais condition causes many other application servers to fail, 
e.g. by crashing. 

15 Thus, when running out of storage space, the appHcation server may automatically suspend logging until 

more storage i^ce becomes avaUable. Logging may then resume when storage space becomes available. In one 
embodiment, it is guaranteed that when the appHcation server suspends logging for lack of storage space, a message 
to tiiat effect wiU be written to the log me. The appHcation server logging faciUty 

disk space to write such a message if necessary. The logging facihty may suspend logging for the duration of the 
20 out-of storage space condition, and then automatically resume logging when Ac condition is corrected. The. 
appHcation server logging faciHty may monitor the amount of available storage spac^ 

periodically and performs this check. 

Figure 23 is a flowchart diagram iUustrating one embodiment of a method for handli^ 

space conditions. As shown, in step 500, an amount of storage space may be reserved, e.g., at the startup time of 
25 the logging service. This storage space may be disk space or another type of media storage space, depending on 
where messages are logged The amount of storage space reserved may vary, but is preferably a restively smaD 
amount suitable for logging an out-of-storage space condition message, as described below. The storage space may 
be reserved m any of various ways, depending on the particular operating system, programmmg language, etc. 

As shown in steps 502 and 504, the amount of storage space currently available may be checked 
30 periodicaUy. For example, the loggmg service may create a tinead that wakes up periodically and performs this 
check. 

If an out-of-storagc-spacc condition is detected then message logging may be su^ 
506. In one embodiment, the logging service may sixnply ignore requests by cUcnt processes to log messages while 
message logging is suspended The logging service may retom an error code to the cHent indicating tiiat the 

35 message was not logged 

In step 508, a message indicating the out-of-storage-space condition may be logged usmg the storage 
space reserved in step 500. In various embodiments, other actions may also be taken in response to an out-of- 
storage space condition. For example, an administrator may be alerted via an email, a page, etc. 
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As shown in step 510, the logging service may periodically check for available storage space and may 
resume message logging if storage space becomes available. For example, a thread may periodically wake up to 
perform this check. Upon resuming message logging, the logging service may of course reserve storage space for 
logging an out-of-storage-space condition again if necessary. 

5 As noted above, Figure 23 represents one embodiment of a method for handling out-of-storagc-space 

conditions, and various steps may be added, combined, altered, etc. For example, tiie logging service may be 
operable to check for declining storage space and may alert an administrator, e.g., via an email, before such a low 
level of storage space is reached that message logging suspension becomes necessary. As another exait^le, in one 
embodiment, the logging service may queue logging requests received from client processes in memory while 

10 message logging is suspended and may attempt to log the messages once storage space becomes available. 

Although the embodiments above have been described in considerable detail, numerous variations and 
modifications will become apparent to those skilled in the art once the above disclosure is folly appreciated. It is 
intended that the foUowing claims be interpreted to embrace all such variations and modification 
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WHAT IS CLAIMED IS: 

1. A method for load balancing requests among a plurality of application servers, liie method 
conjprising: 

cn^Ioying an algorithm to determine an optinial application server for processing a plurality of requests; 
receiving the plurality of requests; 

distributing the plurality of requests among the plurality of application servers for processing; 

wherein said distributing comprises sending a larger portion of the plurality of requests to the optimal 
apphcation server than to any other application server, and distributing at least some of the requests to application 
servers other than the optimal application server. 

2. The method of claim 1, 

wherein said enq>!oying an algorithm comprises assigning a rank to each application server based on 
particular criteria, wherein the rank describes the abihty of the application server to efficiently process requests, 

according to the particular criteria; 

wherein said dcterimning the optnnal application server comprises choosing the most highly ranked 

apphcation server. 

3. The method of claim 2, 

wherein said distributing the pluraUty of requests among the plurality of apphcation servers for processing 
comprises distributing the pluraUty of requests among the plurality of application servers in proportion to the rank 
of the apphcation servers; 

wherein each apphcation server receives a larger portion of the requests ton apphcation servers of lower 

ranks* 

4. The method of claim 2, 

wherein said distributing the plurahty of requests among &c plurality of apphcation servers for processing 
comprises distributing plurahty of incoming requests according to a weighted randomness algorithm; 

wherein the weighted randoinness algorithm utilizes the ranks assigned to the apphcation servcr^^ 

5. Theme&odof claim4, 

v^crein, for each given application server, the weighted randomness algorithm is operable to assign 
icquests to the apphcation server in a probabilistic manner, according to the ran^ 

6. Themediodofclaim3, 

wherein the number of requests assigned to apphcation servers of successively increasing rank increases 
exponentially. 

7. Thcmethod of claim 1, 
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whercin said distributing congirises sending a majority of the plurality of requests to the partictilar 
applicatioa server. 

8. ThemeAodof claim 1, 

5 wherein said distributing conqirises distributing the portion of the plurality of requests tibat arc not sent to 

the optirnal apphcation server evenly aniong the remaining apphcation servers. 

9. The method of claim 1, 

wherein the algorithm utilizes information that is updated periodically. 

10 

10. The method of claim 9, 

wherein the information that is updated periodically comprises server load ijdformation received from each 
application server. 

15 11. The method of claim 1, 

wherein said distributing the plurality of requests among the plurality of application servers for 
processing is performed by a client conqmter. 

12- The method of claim 1, 
20 wherein said distributing the plurality of requests among the plurality of application servers for 

processing is perfoTined by an application server fitjm the pluraUty of j^Hcab 

13. A system comprising: 

a plurality of jqjplication servers; 
25 a cott^uter operable to: 

CBOploy an algorithm to determine an optimal application server for processing a plurality of 

requests; 

receive the plurality of requests; 

distribute the pluraHty of requests aniong the pluraUty of appUcation servers for processing; 
30 wherein said distributing con^jrises sending a larger portion of the plurality of requests to the optimal 

s^lication server ten to any other application server, and distributing at least some of the requests to s^lication 
servers other than die optimal application server. 

14. Tlie system of claim 13, 

35 wherein said employing an algorithm comprises assigning a rank to each application server based on 

particular criteria, whercin the rank describes the ability of the application server to efiOcicntiy process requests, 
according to the particular criteria; 

\idicxein said determining the optimal application server comprises choosing the most highly ranked 
application server. 
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15. Thesystemof clmm 14, 

wherein said distributing Ac plurality of requests among the plurality of application servers for processing 
conqrrises distributing the plurality of requests among the plurality of application servers in proportion to the rank 
5 of the application servers; 

wherein each application server receives a larger portion of the requests than application servers of lower 

ranks, 

16. Thesystemof claim 14, 

10 wherein said distributing the plurality of requests among 4e plurality of application servers for processing 

con^prises distributing the plurality of incoming requests according to a weighted randomness algorithm; 

wherein the weighted randomness algorithm utilizes the ranks assigned to the application servers, 

17. Hie system of claim 16, 

15 >^erein, for each given application server, the weighted randonmess algorithm is operable to assign 

requests to the application server in a probabilistic manner, according to the rank of the application server. 

18. The system of claim 15, 

wherein the number of requests assigned to application servers of suxxcssively increasing rank increases 
20 exponentially. 

19. The system of claim 13, 

■wherein said distributing con^rises sending a majority of the plurality of requests to the particular 
apphcation server, 

25 

20. TTjc system of claim 13, 

wherein said distributing comprises distributing the portion of the plurality of requests that arc not sent to 
the optimal application server evenly among the remaining application servers. 

30 21. The system of claim 13, 

wherein the algorithm utilizes information that is updated periodically. 

22. Thesystemof claim 21, 

wherein the information that is updated periodically conq^rises server load information received from each 
35 application server. 



23. The system of claim 13, 
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wherein the computer operable to distribute the plurality of requests among the plurality of application 
servers for processing is performed by a client computer. 

24. Thesystemof claim 13, 

5 wherein the computer operable to distribute the plurahty of requests among the plurality of application 

servers for processing is performed by an appHcation server from the plurality of application servers. 

25. A memory medium comprising program instractions executable to: 

employ an algorithm to determine an optimal application server for processing a plurality of requests; 
10 receive the plurality of requests; 

distribute the plurality of requests among the plurality of application servers for processing; 

wherein said distributing comprises sending a larger portion of the plurality of requests to the optimal 
application server than to any other application server, and distributing at least some of the requests to application 
servers other than the optimal application server. 

15 

26. The memory medium of claim 25, 

wherein said employing an algorithm conq)rises assigning a rank to each appHcation server based on 
particular criteria, wherein the rank describes the ability of the application server to efiicicntiy process requests, 
according to the particular criteria; 
20 wherein said determining the optimal application server comprises choosing the most highly ranked 

appUcation server. 

27. The memory medium of claim 26, 

wherein said distributing the plurahty of requests among the plurality of application servers for processing 
25 comprises distributing the plurality of requests among the plurality of ^pUcation servers in proportion to the rank 
of the application servers; 

wherein each application server receives a larger portion of the requests than appUcation servers of lower 

ranks. 

30 28. The memory medium of claim 26, 

wherein said distributing the plurality of requests among the plurality of appUcation servers for processing 
comprises distributing the plurality of incoming requests according to a weighted randoomess algorithm; 

wherein the weighted randornness algoritlmi utilizes the ranks assigned to the appHcation servers. 

35 29. The memory medium of claim 28, 

wherein, for each given application server, the weighted randoinness algorithm is operable to assign 
requests to the appUcation server in a probabilistic manner, according to the rank of the appUcation server. 

30. The memory medium of claim 27, . 
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wherein the number of requests assigned to application servers of successively increasing rank increases 
exponentially. 

31. Thememoiy medium of claim 25, 

5 wherein said distributing comprises sending a majority of the plurality of requests to the particular 

application server. 

32. Thememory mediimiof claim25, 

wherein said distnTjutmg conqmses distributing the portion of the pluraUty of rcqu^ 
10 the optimal application server evenly among the remaining application servers, 

33. The memory medium of claim 25, 

wherein the algorithm utilizes information that is updated periodically. 

15 34. Thememory medium of claim 33, 

-vsiicrein the information that is updated periodically con^prises server load informatian received fix>m each 
application server. 
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instantiate new dasstoader 
406 



use new classloader to reload modified class 

408 



purge modified dass from application server 
cache(s) 
410 



Figure 16 
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class is versionable 



^ class is versionable 



> dass is versionable 



no 



class is not versionable 



Figure 17 
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administrator specifies a set of class files to be 
treated as a bundle 
440 



administrator requests dass bundle to be deployed 

442 



deployer manager obtains lock to 
dirtyClasslistLock 
444 



deployer manager copies all dass files in the 
bundle to their appropriate nmtime locations in the 
file system 
446 



deployer manager releases dirtyClassUstLock 

448 



timed thread obtains dirtyClassUstLock and 
dynamically reloads modified dasses in bundle 

450 
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request referencing a JSP component received 

600 



^1 b£ 



check JSP response cache to determine whether a 
cached response satisfies request 
602 



matchtr^g response 
cached? 
604 





cache JSP 
response? 
610 



yes 



create response entry in cache and 
assodate with appropriate criteria set 
612 



no 





store JSP response in response entry 
614 


4 







return JSP response 
616 



Figure 19 
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ScrrcrLoQ | HTTP Log 

0Eresbte Server Evcrl bag 
tog Target — 



MaSoifcec 
Mfibose: 



jevcndog 



iKstvnpie 
jeverUog 



UssmsRioc 



ptcgtalie ~ 



Yes ▼ 



Maximum Entries^ 

y^ftiei^^efv^ [to" 
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Database field Dame 



Description 



Data type 



cvttimc 
evttype 

eytcategoiy 
evtstring 



Date and time the Date/Time 
message was created 

Message type, such as Number 

infonnatkm, warning, or 

error 

Service or ^implication Number 
component ID 

Message text Text 
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Default U'liP variables 


DeHaiilt database fidd name 


Data type 


N/A 


logtiiDe 


Date/Time 


CONTENT^LENGTH 


contentjength 


>iTi ■ 1 1 1 ^-tnr 

Nutnoer 


CONTENT_TYPE 


contenltype 


lext 


HTTP_ACChFi 


accept 


Text 


HTTP^CONNECnON 


connection 


iexx 


HTTPJHOST 


host 


lexi 


HTTP_REFERER 


icfcici 


Text 


HTTPJJSERAGENT 


userjageot 


Text 


PATH JNFO 


nri 


Text 


REMOTE^ADDR 




Text 


REQUEST_METHOD 


method 


Text 


SERVER PROTOCOL 


protocol 


Text 
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reserve storage space at startup of 
logging service 
500 



periodtcaily check for out-of-storage 
space condition 
502 




suspend message logging 
506 



use reserved storage space to log a 
message indicating the out-of-storage 
space condHkHi 
608 



periodically check for available storage 
space and resume message k>gging if 
space is available 
510 
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